On September 24th, 2026, the Cybersecurity and Infrastructure Security Agency (CISA) added a vulnerability in WSO2 API management products to its Known Exploited Vulnerabilities (KEV) catalog following confirmed exploitation in the wild. Tracked as CVE-2026-5430 and recently updated to a CVSS score of 10, the flaw lets an unauthenticated remote attacker forge a JSON Web Token (JWT) that bypasses authentication, allowing access to administrative accounts. It affects the WSO2 API Control Plane, API Manager, Traffic Manager, and Universal Gateway. WSO2 released fixes ahead of the exploitation.
Active exploitation is confirmed. Honeypot sensors captured forged administrator tokens targeting the flaw beginning September 13th, 2026, and CISA has since added it to the KEV catalog. Given the unauthenticated remote access it grants to internet-reachable API infrastructure, Beazley Security recommends affected organizations apply available fixes immediately and conduct a thorough review for any signs of compromise.
Product | Affected Versions |
|---|---|
WSO2 API Control Plane | 4.5.0, 4.6.0 |
WSO2 API Manager | 4.1.0 through 4.6.0 |
WSO2 Traffic Manager | 4.5.0, 4.6.0 |
WSO2 Universal Gateway | 4.5.0, 4.6.0 |
A single upgrade remediates the flaw for each affected product. There is no configuration setting that disables the vulnerable behavior, so patching and network containment are the priority.
Apply the public code fixes in the Carbon API Management and Product APIM repositories or migrate to the latest unaffected release of the affected product.
Apply the vendor-specified update level for your version, or a newer one:
API Control Plane:
4.6.0 update level 22
4.5.0 update level 58
API Manager:
4.6.0 update level 21
4.5.0 update level 57
4.4.0 update level 72
4.3.0 update level 108
4.2.0 update level 197
4.1.0 update level 257
Traffic Manager:
4.6.0 update level 21
4.5.0 update level 56
Universal Gateway:
4.6.0 update level 21
4.5.0 update level 57
Besides performing the updates, organizations running WSO2 should mitigate risk of attackers gaining access to their infrastructure:
Restrict access to internet-facing WSO2 management consoles and gateways to trusted administrative networks until updates are applied.
Because a forged token exposes application credentials, rotate consumer keys, secrets, and administrative credentials, and review administrator accounts for unauthorized additions or changes.
WSO2 has released fixes for all affected products. Open-source users receive the fix through public code changes, while support subscription holders apply the vendor-provided update levels. Full details are available in the official WSO2 security advisory (WSO2-2026-5328).
On September 24th, 2026, CISA added CVE-2026-5430 to its KEV catalog, confirming active exploitation in the wild. watchTowr reported that its honeypot network captured forged JWTs carrying administrator privileges beginning September 13th, 2026.
Defenders should inspect authentication logs for anomalous JWT validation events, such as tokens accepted despite being signed with an unexpected or unsupported algorithm, and successful authentications that do not correspond to a legitimate login.
This can be searched from the WSO2 install ./repository/logs/http_access_*.log for HTTP 200 responses to
/api/am/admin/
/api/am/publisher/
/api/am/devportal/
Organizations should also monitor for newly created or newly privileged administrator accounts; changes to API configurations, routing, or access policies; and administrative activity originating from unfamiliar addresses. Because a forged token yields application credentials and secrets, treat any unexplained use of consumer keys or back-end service credentials as a potential sign of compromise.
CVE-2026-5430 is a signature verification flaw in how WSO2 API management products handle JSON Web Token authentication. The software accepts a token to the endpont /api/am/admin/ signed with an algorithm it does not support and incorrectly treats that token as validly signed. An attacker can therefore craft a JWT that asserts any identity, including an administrator, without possessing a legitimate signing key and present it to bypass authentication entirely. No credentials or user interaction is required. WSO2 credits the Hacktron Team with discovering and reporting the issue.
watchTowr's intel platform reported the in-the-wild activity and observed forged tokens minted with administrator privileges. watchTowr reported that a forged token grants access to every API back-end endpoint, along with the credentials, consumer keys, and secrets of every registered application.
Full technical write-ups and a public proof-of-concept for this WSO2 flaw were not available at the time of publication.
Beazley Security is monitoring client perimeter devices through our Exposure Management Platform to identify impacted devices and support organizations in remediation of any issues found.
We are also conducting threat hunts across our MDR environment to detect potential exploitation attempts against our clients.
If you believe your organization may have been impacted by this attack campaign and need support, please contact our Incident Response team.
On September 23rd, 2026, the Drupal Security Team published advisories addressing 36 vulnerabilities across 16 modules, including five rated critical. Among the most serious is CVE-2026-96355 affecting the widely used Webform module. Given the breadth and severity of these disclosures, organizations running Drupal should review their installations and update any affected modules before attackers weaponize these vulnerabilities.
The vulnerabilities associated with the released advisories enable attackers to perform a multitude of attacks, including remote code execution, stored cross-site scripting, and authorization bypasses. The updates released by Drupal resolve all these vulnerabilities across the modules.
Although active exploitation has not been reported and no public proof-of-concept exploits are known at the time of writing, critical Drupal vulnerabilities have historically been weaponized following disclosure. For example, 2018's "Drupalgeddon2" was exploited at scale shortly after disclosure. Beazley Security recommends affected organizations apply available fixes as soon as possible, prioritizing Webform and Cloud.
CVE | Module | Vulnerability | Affected Versions |
|---|---|---|---|
CVE-2026-96355 | Webform | Remote code execution | < 6.2.12; 6.3.0 before 6.3.1 |
CVE-2026-96388 | tawk.to Live Chat | Cross-site request forgery | < 3.0.4 |
CVE-2026-96374 | Project Browser | Cross-site request forgery | < 2.0.3; 2.1.0 before 2.1.5 |
CVE-2026-96376 | Cloud | Remote code execution | < 7.0.1 |
CVE-2026-96375 | Cloud | Improper TLS certificate validation | < 7.0.1 |
The same release fixed 31 further vulnerabilities in 13 modules, which Drupal rated as moderately critical. Most require an attacker to already hold an authenticated role or depend on a specific site configuration. Webform accounts for 19 of them, and the same Webform upgrade that fixes CVE-2026-96355 resolves all of them.
Module | CVEs | Issue Types | Fixed Version |
|---|---|---|---|
Webform | CVE-2026-96356, CVE-2026-96357, CVE-2026-96358, CVE-2026-96359, CVE-2026-96360, CVE-2026-96361, CVE-2026-96362, CVE-2026-96363, CVE-2026-96364, CVE-2026-96365, CVE-2026-96366, CVE-2026-96367, CVE-2026-96368, CVE-2026-96369, CVE-2026-96370, CVE-2026-96371, CVE-2026-96372, CVE-2026-96373, CVE-2026-96398 | Cross-site scripting, access bypass, server-side request forgery, denial of service, anti-spam bypass | 6.2.12 / 6.3.1 |
AI CKEditor | CVE-2026-96392 | Code execution via Twig templates | 1.4.3 |
REST & JSON API Authentication | CVE-2026-96385 | Access bypass | 3.2.0 |
Webform REST | CVE-2026-96391 | Access bypass | 4.2.1 |
Smart Content | CVE-2026-96386 | Access bypass | 3.2.1 |
Commerce Decoupled Checkout | CVE-2026-96378 | Access bypass | 1.8.0 |
Mermaid Diagram Field | CVE-2026-96384 | Access bypass | 1.0.10 |
Stop Administrator Login | CVE-2026-96387 | Access bypass | 8.x-1.6 |
Editoria11y Accessibility Checker | CVE-2026-96390 | Access bypass | 2.2.23 / 3.0.9 |
Combined Image Style | CVE-2026-96377 | Denial of service | 1.0.7 |
CookieCuttr | CVE-2026-96379 | Cross-site scripting | 2.0.3 |
Diba Carousel Slider | CVE-2026-96382 | Cross-site scripting | 3.0.2 |
CSS Usage Analyzer | CVE-2026-96380 | Access control (forged report data) | Later than 1.0.1 |
Two of these fixes require follow-up:
The Webform update adds a new Administer webform remote post URLs permission, which should be granted only to trusted roles.
Commerce Decoupled Checkout now rejects custom order fields outside an allowlist, so sites that submit additional fields must enable them at /admin/commerce/config/decoupled-checkout before resuming checkout.
Upgrading to fixed versions remediates every vulnerability in this advisory. One Webform upgrade addresses CVE-2026-96355 and its 19 sibling issues, and Cloud 7.0.1 fixes both Cloud vulnerabilities.
Webform: 6.2.12 for the 6.2.x branch, or 6.3.1 for the 6.3.x branch
Cloud: 7.0.1
Project Browser: 2.0.3 for the 2.0.x branch, or 2.1.5 for the 2.1.x branch
tawk.to Live Chat: 3.0.4
After upgrading, complete these steps:
Run Drupal database updates and rebuild caches, as the Cloud and tawk.to advisories require cache rebuilds.
For Cloud sites that use a private certificate authority (CA), configure the CA certificate path for each Kubernetes and VMware connection or ensure the PHP runtime trusts the issuing CA. Cloud 7.0.1 enables certificate verification, and connections will fail without this step.
If organizations cannot upgrade immediately, the following steps may temporarily reduce risk:
Identify webforms that use a custom multiple-value item format containing submission-value tokens and remove those formats until Webform is updated. Only webforms configured this way are exposed to CVE-2026-96355.
Disable the Cloud Kubernetes submodule where it is not in use. Otherwise, restrict permission to add or edit cloud server templates, and the launch cloud server template permissions, to trusted administrators.
Uninstall Project Browser from production sites that do not need it.
These workarounds change site behavior and do not address the cross-site request forgery (CSRF) issue in tawk.to, so treat them as short-term measures only.
The Drupal Security Team has released fixed versions of all affected modules, available from each module's project page on drupal.org. Additional information can be found in the individual Drupal advisories listed below.
One of the most critical flaws released, CVE-2026-96355, stems from how Webform renders submissions. Site builders can define custom display formats for fields that accept multiple values, and those formats can include tokens that insert submitted values. Webform does not exclude these format templates from token replacement. As a result, text an attacker enters into a form is inserted into the template and evaluated as template code when the submission is displayed. What that evaluation achieves depends on the site's configuration and enabled modules, ranging from data exposure to code execution on the server. At the time of writing, it’s unclear whether a common pathing and module configuration enables a generic exploitation of this token replacement issue.
In the Cloud module, CVE-2026-96376 is an operating system command injection. The Kubernetes integration passes the Git branch and repository URL values from cloud server templates to shell commands without sanitization. An attacker who can edit a template can also run commands as the web server user. Exploitation requires the Kubernetes submodule to be enabled and Git to be present on the server. Drew Webber of the Drupal Security Team reported the flaw.
CVE-2026-96375 is a missing TLS certificate check in the Kubernetes and VMware integrations, which lets an attacker who can intercept those connections capture API tokens and other credentials.
CVE-2026-96374 and CVE-2026-96388 are missing CSRF protections on actions in Project Browser and tawk.to. Drupal has not published further technical detail, and no public proof-of-concept exploits are known.
Beazley Security is monitoring client perimeter devices through our Exposure Management Platform to identify impacted devices and support organizations in remediation of any issues found.
We are also conducting threat hunts across our MDR environment to detect potential exploitation attempts against our clients.
If you believe your organization may have been impacted by this attack campaign and need support, please contact our Incident Response team.
On September 22nd, 2026, Check Point released emergency hotfixes for a critical vulnerability in its Management Server products and confirmed that attackers had already exploited it as a zero-day. Tracked as CVE-2026-93616, the vulnerability allows an unauthenticated remote attacker to traverse outside the intended directory in the Management web service and upload scripts to execute on the server. CISA added the vulnerability to its Known Exploited Vulnerabilities (KEV) catalog the same day.
The Management Server is the central administrative plane for a Check Point deployment. It stores and distributes security policies to manage gateways and collects logs across the enterprise network. This allows an attacker who executes code there to control firewall policy and gain access to operational and audit data, which the organization relies on to detect an intrusion. Check Point observed the earliest attacks on July 23rd, 2026, described the activity as targeted and limited, and stated it is aware of a handful of customers who were attacked. The vendor has not attributed the intrusions or described what the attackers did after gaining code execution.
Active exploitation is confirmed, and this is the latest in a run of Check Point management and gateway flaws that attackers have leveraged over the past year. Given the privileged position of the Management Server and the confirmed exploitation preceding the fix, Beazley Security recommends affected organizations apply available fixes immediately and conduct a thorough review for any signs of compromise.
The vulnerability affects Security Management Server, Multi-Domain Security Management Server, Log Server, Multi-Domain Log Server, and SmartEvent.
Release | Affected Versions |
|---|---|
R82.20 | No Jumbo Hotfix installed |
R82.10 | Jumbo Hotfix Take 44 and below |
R82 | Jumbo Hotfix Take 126 and below |
R81.20 | Jumbo Hotfix Take 166 and below |
R81.10 | Jumbo Hotfix Take 190 and below (end of support) |
R81, R80.40, R80.30, R80.20, R80.10, R80 | All versions (end of support) |
Smart-1 Cloud is not vulnerable, as Check Point has already applied the fix.
Check Point Firewall Appliances and Spark Firewalls are not affected by this issue.
Upgrading is the only complete remediation. Administrators should not assume LivePatch protects them: LivePatch Takes 28 and 29 do not correct this flaw, and Check Point states no LivePatch will be available given the nature of the fix.
Where organizations cannot patch immediately, the following steps reduce exposure:
Place the Management Server behind a Security Gateway or Check Point firewall and restrict access to TCP port 19009 to trusted IP addresses.
Limit the Trusted Clients list to known internal administrative addresses via Manage & Settings > Permissions & Administrators > Trusted Clients in SmartConsole.
Treat both as temporary measures. Because Check Point has asserted exploitation predated the fix, applying the hotfix takes priority over access controls alone, and patching does not reveal whether a server was already attacked.
Check Point has released fixes. Customer-managed servers require the R82.20 Security Hotfix or a corrected Jumbo Hotfix Accumulator, with the correction included in R82.10 Take 45, R82 Take 127, R81.20 Take 170, and R81.10 Take 192 or later.
Vendor-hosted Smart-1 Cloud instances have already been updated.
Fixed builds, hunting guidance, and indicators are published in Check Point support article sk1000171 and the accompanying vendor advisory.
Hunt across every management, logging, and SmartEvent server, not only those exposed to the internet.
Check Point provided the following two checks for compromise:
Look for unusually long usernames recorded in the cpm.elg logs, and then correlate those entries against FWM or MDS core dumps generated around the same time.
grep -nHP "login\(loginRequest=LoginRequest\{authenticationInfo=AuthenticationInfoBase\{username='[^' ]{1001,}'" "$MDS_FWDIR"/log/cpm.elg*
If that search returns results, validate if a FWM/MDS core dump was generated at the same time.
ls -l /var/log/dump/usermode/ | grep -e fwm -e mds
The presence of a core dump at the same time as the login attempt indicates potential exploitation.
Search for ReflectionUtils errors reporting that the service failed to load an allResourceFiles map. Examine the paths returned by those errors for traversal sequences, such as ../../. Either pattern warrants immediate investigation.
grep -E "ERROR.*upgrade\.base\.ReflectionUtils.*Failed to load allResourceFiles map from" $MDS_FWDIR/log/cpm.elg*
Where either pattern appears, preserve the relevant logs and core dumps before they are overwritten or removed, isolate the affected server where operations allow, review what the server did afterward, and contact Check Point Support.
Check Point has claimed it will continue to update its advisory, so administrators should monitor it for revised guidance and additional indicators, and watch for official communications from Check Point about specific exploitation within their cloud userbase.
CVE-2026-93616 combines directory traversal with unsafe file upload handling in the Check Point Management web service. The service does not properly constrain which files and directories a request can reach. By manipulating the file path in a request with relative paths, an attacker causes the service to write a script to an arbitrary location. This also enables execution to load an arbitrary Java class.
Check Point has withheld deeper technical detail and has not described the payloads used in the July attacks. No public proof-of-concept (PoC) exploit is available at the time of writing. However, because exploitation of this vulnerability appears trivial, we would expect public PoC examples in the upcoming days.
Beazley Security is monitoring client perimeter devices through our Exposure Management Platform to identify impacted devices and support organizations in remediation of any issues found.
We are also conducting threat hunts across our MDR environment to detect potential exploitation attempts against our clients.
If you believe your organization may have been impacted by this attack campaign and need support, please contact our Incident Response team.
On September 22nd, 2026, F5 published an advisory for a critical vulnerability in BIG-IP Access Policy Manager (APM) and confirmed active exploitation in the wild. Tracked as CVE-2026-94127, the flaw lets an unauthenticated, remote attacker send crafted traffic to an affected virtual server and execute code on the appliance.
BIG-IP APM sits at the network edge and brokers remote access to internal applications, which makes a compromised appliance both a foothold and a position to observe or redirect user traffic. F5 notes that systems running in Appliance mode are also affected, and only virtual servers configured with both an APM access policy and an OAuth profile are vulnerable.
Given confirmed exploitation in the wild, unauthenticated network accessibility, and the sensitive data these systems protect in enterprise environments, Beazley Security recommends affected organizations apply available fixes as soon as possible.
Only BIG-IP systems with both an APM access policy and an OAuth profile configured on a virtual server are vulnerable. Other BIG-IP modules, BIG-IQ, F5OS, NGINX products, and F5 Distributed Cloud services are not affected.
Product | Affected Versions | Fixed In |
BIG-IP APM 21.x | 21.1.0 | Hotfix-BIGIP-21.1.0.2.0.30.22-ENG |
BIG-IP APM 17.x | 17.5.0 - 17.5.1 | Hotfix-BIGIP-17.5.1.9.0.160.12-ENG |
BIG-IP APM 17.x | 17.1.0 - 17.1.3 | Hotfix-BIGIP-17.1.3.5.0.41.14-ENG |
F5 evaluated only versions that have not reached End of Technical Support. Organizations running end-of-support releases should assume exposure and upgrade.
Because exploitation in the wild has been confirmed, Beazley Security recommends patching as the best mitigation. If patching cannot be immediately performed, the following may help to temporarily reduce risk:
Prioritize virtual servers that have both an APM access policy and an OAuth profile attached as the combination is the precondition for exploitation of this flaw.
Contact F5 Support to obtain the vendor-supplied iRule mitigation, and apply it to the affected APM virtual servers.
Preserve forensic evidence, including TMM core files and APM and audit logs, before making configuration changes or rebooting.
F5 has released engineering hotfixes for the affected 17.x and 21.x branches, available from F5 Downloads. Full version details and diagnostic guidance are in the F5 advisory and can be found here.
On September 22nd, 2026, CISA added CVE-2026-94127 to its Known Exploited Vulnerabilities (KEV) catalog, confirming active exploitation in the wild. F5 has stated the vulnerability has been exploited but has not published attacker infrastructure or tooling indicators. No public proof-of-concept exploit is known at the time of writing.
F5 describes the attack chain as three events occurring close together: repeated OAuth authentication failures, followed by suspicious commands, followed by a crash of the Traffic Management Microkernel (TMM).
Defenders can review the APM logs in /var/log/apm for repeated UserInfo request failures carrying an invalid token error. Isolated occurrences are normal, so the signal may not always indicate successful exploitation:
<DATE> <HOST> err tmm1[30975]: 01990004:3: <PROFILE_NAME>: Request UserInfo from Source ID (null) IP <IP> failed. Error Code (invalid_token) Error Description (The access token is invalid.)
When a cluster of failures are observed, timestamps in the audit logs in /var/log/audit can be correlated around that window for suspicious commands. F5 has observed the TMM entering a loop that causes the SOD daemon to abort the process, so a core file alongside the log activity above could warrant further investigation.
OAuth profiles allow BIG-IP to process authorization and identity-related requests, while APM access policies evaluate those requests and determine the actions that follow.
The flaw confirmed by F5 as exploited is a heap-based buffer overflow in the OAuth handling path of the Traffic Management Microkernel, the component that processes data plane traffic on BIG-IP. When a virtual server is configured with both an APM access policy and an OAuth profile, specially crafted requests corrupt memory during OAuth processing. That corruption leads to code execution on the appliance without an attacker requiring valid credentials.
F5's advisory includes indicators associated with observed attacks, including repeated OAuth authentication failures, suspicious command activity, and subsequent Traffic Management Microkernel (TMM) crash events. F5 did not describe the exploitation process or explain how these events relate to each stage of exploitation. See the Indicators of Compromise section of this advisory for more information, or F5’s official advisory here.
Although F5’s advisory states the issue was initially discovered internally, CISA added CVE-2026-94127 to its Known Exploited Vulnerabilities (KEV) Catalog on September 22, 2026, based on the reported evidence of active exploitation.
Beazley Security is monitoring client perimeter devices through our Exposure Management Platform to identify impacted devices and support organizations in remediation of any issues found.
We are also conducting threat hunts across our MDR environment to detect potential exploitation attempts against our clients.
If you believe your organization may have been impacted by this attack campaign and need support, please contact our Incident Response team.
On September 22nd, WordPress published an advisory regarding a critical vulnerability reported in their flagship CMS software. Tracked as CVE-2026-87902, the flaw lets an unauthenticated, remote attacker manipulate page template resolution to include arbitrary PHP files from outside the active theme directory. Under specific server and theme conditions, the vulnerability can lead to remote code execution and full site compromise.
WordPress Core powers a large share of the public web, and this flaw sits in the core software rather than an optional plugin or theme. For exploitation, the active parent or child theme must carry a top-level directory whose name begins with “page-”, and the server must hold a readable PHP file that does something useful when included.
Active probing of internet-facing WordPress sites was observed within hours of the patch, using payloads built from the published fix. Given the size of the exposed population, ease of exploitation on affected configurations, and the absence of a vendor workaround, Beazley Security recommends affected organizations apply available fixes as soon as possible.
Product | Affected versions | Patched versions |
7.1 | 7.1.0 - 7.1.1 | 7.1.2 |
7.0 | 7.0.0 - 7.0.5 | 7.0.6 |
6.9 | 6.9.0 - 6.9.8 | 6.9.9 |
6.8 | 6.8.0 - 6.8.9 | 6.8.10 |
6.7 | 6.7.0 - 6.7.8 | 6.7.9 |
6.6 | 6.6.0 - 6.6.8 | 6.6.9 |
6.5 | 6.5.0 - 6.5.11 | 6.5.12 |
6.4 | 6.4.0 - 6.4.11 | 6.4.12 |
6.3 | 6.3.0 - 6.3.11 | 6.3.12 |
6.2 | 6.2.0 - 6.2.12 | 6.2.13 |
6.1 | 6.1.0 - 6.1.13 | 6.1.14 |
6.0 | 6.0.0 - 6.0.15 | 6.0.16 |
5.9 | 5.9.0 - 5.9.17 | 5.9.18 |
5.8 | 5.8.0 - 5.8.16 | 5.8.17 |
5.7 | 5.7.0 - 5.7.18 | 5.7.19 |
5.6 | 5.6.0 - 5.6.20 | 5.6.21 |
5.5 | 5.5.0 - 5.5.21 | 5.5.22 |
5.4 | 5.4.0 - 5.4.22 | 5.4.23 |
5.3 | 5.3.0 - 5.3.24 | 5.3.25 |
5.2 | 5.2.0 - 5.2.27 | 5.2.28 |
5.1 | 5.1.0 - 5.1.25 | 5.1.26 |
5.0 | 5.0.0 - 5.0.28 | 5.0.29 |
4.9 | 4.9.0 - 4.9.32 | 4.9.33 |
4.8 | 4.8.0 - 4.8.31 | 4.8.32 |
4.7 | 4.7.0 - 4.7.36 | 4.7.37 |
CVE-2026-87902 was found in a core component and affects all versions of WordPress. While many affected versions are no longer officially supported, the WordPress Foundation released patches for all versions of the CMS software back to 4.7, as a courtesy to users.
WordPress has not published a workaround and affected site owners should update to the fixed release for their branch as soon as possible. If security updates cannot be immediately applied, the following may help to temporarily reduce risk:
The path traversal string is delivered through the “pagename” query variable in an incoming HTTP request. Monitoring and blocking traditional directory traversal sequences in that variable via web application firewall or reverse proxy (if available) would provide some measure of protection.
A CVE-2026-87902 attack chain will rely on a theme package containing a top-level directory whose name begins with “page-“. Removing any installed themes that match that precondition may also help to reduce risk.
Official fixes are available from WordPress. Sites with automatic background updates enabled receive the update without administrator action, otherwise users can update from the Updates screen in the WordPress dashboard or download the release directly from WordPress.org. WordPress backported the fix to every branch still eligible for security fixes as far as 4.7 to address the critical path traversal vulnerability.
WordPress Core is vulnerable to Local File Inclusion via the template loading functions in versions up to and including 7.1.1. The function resolved a caller-supplied template name against the theme directories without verifying the result stayed within them, so a template name containing .. could resolve to a readable PHP file outside the active theme and be included.
The bug is simple, and is at its core a missing validation check on HTTP parameter data. WordPress is open source, and we can easily view a vulnerable version of the code on the WordPress github.
In that version of the code base, in /wp-includes/template.php, line 487 is the affected line of code:
$templates = array();
if ( $template && 0 === validate_file( $template ) ) {
$templates[] = $template;
}
if ( $pagename ) {
$pagename_decoded = urldecode( $pagename );
if ( $pagename_decoded !== $pagename ) {
$templates[] = "page-{$pagename_decoded}.php";
}
$templates[] = "page-{$pagename}.php";
}
Proper validation checks are applied to the $template variable, but not to the $pagename variable, which is attacker-controlled. That variable is then prepended with “page-“, and appended with “.php” to create a URL to redirect to.
An attacker can thus inject a traversal string in the middle of that string and call any arbitrary .php script on the server. Depending on what is available, this can easily lead to remote code execution.
Beazley Security is monitoring client perimeter devices through our Exposure Management Platform to identify impacted devices and support organizations in remediation of any issues found.
We are also conducting threat hunts across our MDR environment to detect potential exploitation attempts against our clients.
If you believe your organization may have been impacted by this attack campaign and need support, please contact our Incident Response team.
On September 16th, 2026, Cisco disclosed a critical vulnerability in Identity Services Engine (ISE) and confirmed it is under active exploitation. Tracked as CVE-2026-76460, the flaw stems from insufficient authentication control on an API endpoint. Cisco states that successful exploitation can give an attacker command execution with root privileges. CISA added the vulnerability to its Known Exploited Vulnerabilities (KEV) catalog the same day.
ISE is a centralized network access control and policy platform. It authenticates users, profiles devices, evaluates security posture, and controls access to wired, wireless, and VPN networks. An attacker with root on an ISE deployment can read and alter the identity and policy data it holds. Cisco has released fixed software.
Given confirmed exploitation, root-level impact, and the position ISE occupies in enterprise identity infrastructure, Beazley Security recommends affected organizations apply available fixes immediately and conduct a thorough review for any signs of compromise.
Cisco ISE and ISE Passive Identity Connector (ISE-PIC) releases 3.0 through 3.5 are affected, regardless of device configuration.
Product Release | Affected Versions | First Fixed Release |
Cisco ISE / ISE-PIC 3.0 | All | No fix, migrate to a supported release |
Cisco ISE / ISE-PIC 3.1 | Before 3.1 Patch 12 | 3.1 Patch 12 |
Cisco ISE / ISE-PIC 3.2 | Before 3.2 Patch 11 | 3.2 Patch 11 |
Cisco ISE / ISE-PIC 3.3 | Before 3.3 Patch 12 | 3.3 Patch 12 |
Cisco ISE / ISE-PIC 3.4 | Before 3.4 Patch 7 | 3.4 Patch 7 |
Cisco ISE / ISE-PIC 3.5 | Before 3.5 Patch 4 | 3.5 Patch 4 |
Cisco states there are no workarounds that address this vulnerability, so patching is the only remediation. Release 3.0 is no longer maintained, and releases 3.1 and 3.2 receive critical fixes only, so organizations running those trains should plan a migration to 3.3 Patch 12, 3.4 Patch 7, or 3.5 Patch 4.
Where an upgrade cannot happen immediately, the following steps reduce exposure:
Apply infrastructure access control lists (iACLs) that permit only required management and control plane traffic destined for ISE nodes, blocking untrusted networks from reaching the management interface.
Restrict management interface reachability to administrative networks, and confirm no ISE node is exposed to the internet.
If exploitation is suspected on a node, re-image that node and restore from a configuration backup rather than attempting to clean it in place.
Cisco has released fixed software for all supported versions. Customers should download the applicable patch through their normal Cisco software update channel, and details are available in the official Cisco security advisory. Release 3.0 does not receive a fix and requires migration to a supported release.
On September 16th, 2026, CISA added CVE-2026-76460 to its Known Exploited Vulnerabilities (KEV) catalog, confirming active exploitation in the wild. Cisco has confirmed exploitation independently but has not published attacker infrastructure or campaign details.
Cisco recommends review of the the ISE access log for unexpected or suspicious usernames, which is the primary artifact of an exploitation attempt. Defenders can review the ise-kong access log, reachable from the admin CLI with show logging application ise-kong/access.log. Any unexpected username in that output warrants investigation.
Cisco has released limited technical detail and no public proof-of-concept exploit is known at the time of publication. The vulnerability is an authentication bypass caused by insufficient authentication control on an ISE API endpoint. A crafted request to that endpoint is served without the authentication the interface is supposed to require, which hands an unauthenticated attacker the access of a legitimate management user.
The flaw is reachable regardless of device configuration where the API is exposed, so no optional feature or specific deployment mode is needed to trigger it. The resulting access can escalate to command execution with root privileges on the underlying operating system.
Beazley Security is monitoring client perimeter devices through our Exposure Management Platform to identify impacted devices and support organizations in remediation of any issues found.
We are also conducting threat hunts across our MDR environment to detect potential exploitation attempts against our clients.
If you believe your organization may have been impacted by this attack campaign and need support, please contact our Incident Response team.
On September 14th, 2026, Cisco published a security hardening release for Cisco Secure Email Gateway and Cisco Secure Email and Web Manager, disclosing five vulnerabilities its own engineering team found during an internal security review. The most severe of these, tracked as CVE-2026-76443, allows an unauthenticated remote attacker to send crafted input that the appliance executes rather than treats as data. The remaining four are part of the same disclosure rather than steps in a single exploit chain. They all allow attackers to access internal information that can be leveraged to gain control of Cisco Secure Email instances. Cisco states that all five vulnerabilities affect the products regardless of device configuration.
Secure Email Gateway and Secure Email and Web Manager sit at the network edge and process inbound and outbound mail for the organizations that deploy them, which puts every message and the appliance's management plane within reach of anyone who compromises one. Cisco confirmed that one vulnerability belonging to the same improper neutralization class as CVE-2026-76443, tracked separately as CVE-2026-76461, is under active exploitation and was added to CISA's Known Exploited Vulnerabilities catalog on September 14th. Cisco patched a maximum-severity AsyncOS flaw in these same appliances in January 2026 after it was exploited as a zero-day beginning in November 2025.
Cisco reports no evidence that any of the five vulnerabilities in this hardening release have been exploited, and no public proof-of-concept code is known for them. Given that attackers are already operating against this appliance family and that a single upgrade remediates all five alongside the exploited flaw, Beazley Security recommends affected organizations apply available fixes immediately and conduct a thorough review for any signs of compromise.
All five vulnerabilities affect the same products and releases. Cisco confirms they do not affect Cisco Secure Web Appliance.
Product | Affected Versions | Fixed Version |
|---|---|---|
Cisco Secure Email Gateway | 15.5 16.0 16.5 | 15.5.5-014 (No fix released or planned) 16.5.0-780 |
Cisco Secure Email and Web Manager | 15.5 16.0 16.5 | 15.5.5-006 (No fix released or planned) 16.5.0-429 |
Release 16.0 did not receive a fix. Migrate those devices directly to a fixed release.
Cisco states there are no workarounds for these vulnerabilities. Upgrading is the only remediation, and a single upgrade to a fixed release addresses all five vulnerabilities.
Upgrade over the network through the web-based management interface:
Choose System Administration > System Upgrade.
Click Upgrade Options.
Click Download and Install.
Choose a fixed release from the table above.
Select the appropriate options in the Upgrade Preparation area.
Click Proceed. The device reboots when the upgrade completes.
Administrators who prefer the CLI can run upgrade, enter DOWNLOADINSTALL, choose a fixed release, and work through the remaining prompts. The device will reboot once the upgrade completes.
Where operationally possible, restrict administrative access to these appliances to trusted internal networks while the upgrade is scheduled.
Cisco has released fixed software for both affected products, and customers must apply it themselves. Version details and the full vulnerability breakdown are available in the official Cisco advisory.
Cisco disclosed these five vulnerabilities differently than a typical advisory, and the difference matters when reading them. Rather than assigning one identifier per flaw, Cisco grouped the issues by their underlying Common Weakness Enumeration class and assigned a single CVE to each grouping. Each identifier represents a set of related defects, not a single bug. Cisco says it took this approach to streamline patching and disclosure.
The practical consequence is that Cisco has not published technical details per issue. They have provided no affected endpoints, no root cause, and no reproduction path for any of the five. What is known is the class and the reachability. All five are remotely reachable without authentication, and Cisco states they apply regardless of device configuration, so there is no feature to disable or setting to check that takes a device out of scope.
CVE-2026-76443 is the most critical of these groupings to prioritize remediation. It covers improper neutralization, which includes both command injection and SQL injection, and it is the same weakness class as CVE-2026-76461, which Cisco has already confirmed is under active exploitation. That flaw is tracked and patched separately. Nothing published thus far indicates that the issues grouped under CVE-2026-76443 are reachable by the same code path, but they share a class with a defect that attackers have already proven they can reach.
Beazley Security is monitoring client perimeter devices through our Exposure Management Platform to identify impacted devices and support organizations in remediation of any issues found.
We are also conducting threat hunts across our MDR environment to detect potential exploitation attempts against our clients.
If you believe your organization may have been impacted by this attack campaign and need support, please contact our Incident Response team.
On September 14th, 2026, Cisco disclosed a critical vulnerability in the email parsing logic of AsyncOS Software for Cisco Secure Email Gateway. Tracked as CVE-2026-76461, CISA added the vulnerability to its Known Exploited Vulnerabilities (KEV) catalog the same day, confirming exploitation in the wild. Cisco confirms the vulnerability affects both physical and virtual appliances regardless of device configuration
The flaw lets an unauthenticated, remote attacker send a crafted email message containing malicious SQL statements and execute arbitrary commands with root privileges on the underlying operating system. Successful exploitation could give an attacker full control of the mail gateway, exposing sensitive data and providing a trusted foothold inside the network.
Given confirmed in-the-wild exploitation, root-level impact, and the absence of any workaround, Beazley Security recommends affected organizations apply available fixes immediately and conduct a thorough review for any signs of compromise.
Product | Affected Versions (Examples) | Fixed Release |
Cisco Secure Email Gateway (AsyncOS) | 15.5 and earlier (e.g., 13.0.0-392, 13.5.1-277, 14.x, 15.x) | 15.5.5-014 |
Cisco Secure Email Gateway (AsyncOS) | 16.0.x (e.g., 16.0.0-050 through 16.0.4-016) | 16.0.4-302 |
Cisco Secure Email Gateway (AsyncOS) | 16.5.x | 16.5.0-780 |
Cisco confirmed CVE-2026-76461 does not affect Secure Email and Web Manager, and Secure Web Appliance.
Cisco states there are no workarounds for this vulnerability. Upgrading to a fixed AsyncOS release is the only remediation, and Cisco recommends customers migrate to Release 16.5.0-780 to fix this flaw. See the “Patches” section of this advisory for more information on patching.
Cisco has released fixed AsyncOS software for customer-managed Secure Email Gateway appliances, and details are available in the official Cisco advisory. Cisco has already upgraded all Cisco Secure Email Cloud devices to Release 16.5.0-780.
Administrators can upgrade an affected device through the web-based management interface as follows:
1. Choose System Administration > System Upgrade.
2. Click Upgrade Options, then Download and Install.
3. Choose the target release and set the options in the Upgrade Preparation area.
4. Click Proceed. The device reboots when the upgrade completes.
Administrators can also run `upgrade` from the CLI and enter `DOWNLOADINSTALL`.
If prior exploitation is suspected, patching alone will not fully address the risk. Cisco recommends contacting Cisco TAC for additional guidance and support.
On September 14th, 2026, CISA added CVE-2026-76461 to its Known Exploited Vulnerabilities (KEV) catalog, confirming active exploitation in the wild. Cisco states they have directly contacted Secure Email Cloud customers whose devices showed evidence of malicious activity.
Defenders can review the IronPort text mail logs (`mail_logs` by default) for unexpected SQL statements. Cisco provided the following example of how malicious SQL statements could be detected. If the appliance is part of a cluster, defenders should review the logs on every cluster member:
cisco-esa> grep -i "COPY.*TO PROGRAM" [IronPort Text Mail Logs Log name - Default: mail_logs]
Because successful exploitation grants root privileges, an attacker can remove or hide artifacts and on-device evidence may be unreliable. Defenders can also cross-check network and firewall logs collected outside the appliance for unexpected outbound uploads from the gateway to external addresses and for downloads from known malicious infrastructure.
The flaw is a SQL injection in the code that parses inbound email. Cisco has not published the specific field or parser involved, but the flaw allows an attacker to craft an email containing SQL syntax, send it through the gateway, and the parsing logic passes that content into a database query without adequate validation. Once the attacker controls SQL execution, they can escalate from database access to operating system command execution as root.
Exploitation requires no authentication or user interaction, and attackers can exploit the appliance through its normal handling and processing of incoming mail. Cisco also confirms the vulnerability exists regardless of device configuration, leaving no configuration-based workaround to reduce exposure while patching.
Cisco confirmed the vulnerability is being actively exploited after identifying it during investigation of a customer support case and the finding indicates the flaw was exploited prior to public disclosure. No public proof-of-concept exploit was known at the time of this writing.
Beazley Security is monitoring client perimeter devices through our Exposure Management Platform to identify impacted devices and support organizations in remediation of any issues found.
We are also conducting threat hunts across our MDR environment to detect potential exploitation attempts against our clients.
If you believe your organization may have been impacted by this attack campaign and need support, please contact our Incident Response team.
On September 11th, 2026, CISA added a critical GitLab vulnerability to its Known Exploited Vulnerabilities (KEV) catalog following confirmed exploitation in the wild. Tracked as CVE-2026-85706, the flaw lets an unauthenticated, remote attacker read any file the GitLab service account can access on a self-managed GitLab Community Edition or Enterprise Edition server.
GitLab servers hold source code, deployment configuration, and the credentials that drive CI/CD pipelines. Arbitrary file read on that host exposes secrets rather than just data: database credentials, SSH keys, deploy tokens, and pipeline variables that an attacker can reuse to access connected cloud accounts, registries, and production systems are also affected. Self-managed instances exposed to the internet carry the highest risk. GitLab.com and GitLab Dedicated environments were addressed by the vendor and require no customer action.
Multiple working proof-of-concept exploits are publicly available, and the attack requires no authentication, no user interaction, and no unusual configuration. Given the trivial exploitation path and the concentration of credentials on a typical GitLab host, Beazley Security recommends affected organizations apply available fixes immediately and conduct a thorough review for any signs of compromise.
Product | Affected Versions | Fixed Versions |
|---|---|---|
GitLab CE and EE | 18.7 through 19.1.7 | 19.1.8 |
GitLab CE and EE | 19.2.0 through 19.2.5 | 19.2.6 |
GitLab CE and EE | 19.3.0 through 19.3.1 | 19.3.2 |
To address this vulnerability, upgrade self-managed GitLab CE and EE instances to 19.1.8, 19.2.6, or 19.3.2, matching the release branch already in use. A single upgrade remediates the vulnerability. Multi-node deployments can use GitLab's zero-downtime upgrade procedure, and of the fixed releases only 19.3.2 carries post-deployment migrations.
Where an immediate upgrade is not possible, the following steps reduce exposure:
Restrict network access to the GitLab instance, removing it from public internet exposure or limiting connectivity to trusted IP ranges.
Review whether any project on the instance is set to public visibility, since a public project is the precondition that makes the endpoint reachable without authentication.
Treat any instance that was internet-facing and unpatched after September 10th, 2026, as potentially exposed. Rotate secrets stored on or reachable from the GitLab server, including database credentials, SSH keys, deploy tokens, and CI/CD variables.
GitLab.com and GitLab Dedicated environments have already been updated by the vendor. GitLab has released fixes for self-managed installations, and upgrade details are available in the vendor's patch release notes linked below.
watchTowr reported detecting probes against its honeypot network beginning at 06:00 UTC on September 11th, roughly one day after the patch became available. Treat any instance that was internet-facing and unpatched after September 10th, 2026, as potentially exposed.
Organizations should review web server, reverse proxy, and GitLab API request logs for HTTP POST requests to /api/v4/projects/{id}/repository/commits/ that carry a file.path parameter. Unauthenticated requests to that endpoint, particularly in bursts or from unfamiliar IP addresses and hosting providers, should be treated as suspicious. Requests referencing configuration files, log files, or key material are the strongest signal of a compromise attempt.
Follow any confirmed file read with a credential review. Watch for use of GitLab-held secrets elsewhere in the environment: unexpected CI/CD job runs, new or modified deploy tokens and personal access tokens, SSH authentication from unrecognized sources, and pivoting behavior like logins to cloud or registry accounts whose credentials were stored on the server.
The vulnerability stems from the repository commits API endpoint at /api/v4/projects/{id}/repository/commits/, which accepts a file path from the request and fails to confine it to the repository directory. This endpoint also fails to enforce authentication. This combination lets an attacker supply a traversal sequence in a file.path parameter and read any file the GitLab process can open on the underlying host.
The only prerequisite is that the instance hosts at least one public project, which supplies a valid project identifier for the request. No credentials, tokens, or user interaction are needed, and the attack is a single HTTP request against a standard API route.
Several fully functional exploit scripts are published publicly, which removes any meaningful barrier to mass exploitation.
Beazley Security is monitoring client perimeter devices through our Exposure Management Platform to identify impacted devices and support organizations in remediation of any issues found.
We are also conducting threat hunts across our MDR environment to detect potential exploitation attempts against our clients.
If you believe your organization may have been impacted by this attack campaign and need support, please contact our Incident Response team.
On September 8th, 2026, SAP disclosed a critical vulnerability in the SAP kernel as part of its September Security Patch Day. Tracked as CVE-2026-44756, the vulnerability grants an unauthenticated attacker remote code execution on a target SAP host. SAP products are commonly deployed internet facing, and successful compromise provides threat actors initial access into an organization’s network.
The vulnerability is in the Extended Passport Processing system, a core SAP component that exists in most SAP products, including Business Suite, NetWeaver, Enterprise Portal, Solution Manager, and others. In addition to initial access, these products often process critical business and client data, which would be immediately exposed on successful exploit.
CVE-2026-44756 was discovered and reported by security company Onapsis, and security patches were available at time of public disclosure by SAP. No in-depth technical details or proof-of-concept exploit code are available at time of writing, and there are currently no reports of this exploit being used by threat actors in-the-wild. However, given the unauthenticated reach into business-critical systems, Beazley Security recommends affected organizations apply available fixes as soon as possible, prioritizing internet-facing systems.
Product | Affected Versions | Fixed Versions |
|---|---|---|
SAP KERNEL | 7.22, 7.53, 7.54, 7.77, 7.89, 7.93, 8.04, 9.16, 9.18, 9.19, 9.20 | Addressed in SAP Note 374769 |
SAP KRNL64UC | 7.22, 7.22EXT, 7.53, 8.04 | Addressed in SAP Note 374769 |
SAP KRNL64NUC | 7.22, 7.22EXT | Addressed in SAP Note 374769 |
SAP WEBDISP | 9.16, 9.18, 9.19, 9.20 | Addressed in SAP Note 374769 |
Patching is the only effective remediation. Because the vulnerable EPP code is reachable over web requests, the SAP GUI protocol, and RFC connections, blocking any one protocol leaves the others open, and no network control should be treated as equivalent to the patch. Tightening SAP roles, user locks, or password policies have are also insufficient, as the vulnerable code runs before those checks are evaluated. Organizations should:
Inventory every system in the SAP landscape that runs an affected kernel, including Web Dispatcher instances.
Apply the kernel patch to internet-facing systems first, then to internal instances.
Remove unnecessary external exposure of SAP web interfaces while the rollout is in progress.
Maintain visibility into the SAP application layer so exploitation attempts can be detected and investigated before patching completes.
SAP released Security Note 3747649 on September 8th, 2026, covering the affected ABAP and Java kernels and the supported SAP Web Dispatcher releases. A single kernel patch closes the known exploitation vectors. Administrators should consult SAP’s September 2026 Security Patch Day guidance to determine which systems in their landscape require the update.
The Extended Passport is a core SAP component that facilitates tracing and troubleshooting. As a low-level mechanism, this object is created for every user session, before authentication. It is also active by default, without any changes to configuration. Additionally, the vulnerable code is reported to affect three critical interfaces:
Web layer, which handles HTTP based applications and integrations
SAP GUI layer, which handles SAP GUI logins
RFC layer, or Remote Function Call, which is how SAP systems programmatically communicate with each other and third-party integrations
Beazley Security is monitoring client perimeter devices through our Exposure Management Platform to identify impacted devices and support organizations in remediation of any issues found.
We are also conducting threat hunts across our MDR environment to detect potential exploitation attempts against our clients.
If you believe your organization may have been impacted by this attack campaign and need support, please contact our Incident Response team.