#criticalvulnerability

Read Time:3 Minute, 48 Second

A Decade-Old Bug With a Perfect Severity ScoreA critical certificate validation flaw affecting LXD and Incus — two prominent platforms for managing Linux containers and virtual machines — could allow a remote attacker to bypass authentication entirely and seize control of a cluster and the workloads running on it. Incus, which forked from LXD, rates its version of the bug at a maximum CVSS score of 10.0. Canonical’s corresponding LXD advisory, tracked as CVE-2026-112816, describes an unauthenticated path to full cluster and virtual machine access, even though Ubuntu’s own classification lists it as only Medium severity.

According to the Incus security advisory published October 29, the flaw has existed since the project’s very first release — meaning it has been present, unnoticed, for the platform’s entire lifetime. Canonical’s related record for LXD followed on October 30.

The Problem: Validating the Wrong ThingAt the heart of the bug is a basic mismatch between what a TLS handshake actually proves and what LXD and Incus assumed it proved. During a standard HTTPS handshake, a client proves it holds the private key corresponding to the first certificate it presents — but any additional certificates included later in that chain are entirely under the client’s control and were never independently verified.

The authentication logic in LXD and Incus, however, checked every certificate in the submitted chain against the server’s trust store, not just the one whose ownership had actually been proven. That gap between “proving you hold a key” and “being trusted as a particular identity” is exactly what an attacker can exploit: by appending the public portion of a trusted certificate to their own certificate chain, an attacker can be accepted as that certificate’s legitimate owner — without ever possessing its private key.

Crucially, public certificates are not secret. Servers hand them out freely during ordinary TLS handshakes, which means an attacker doesn’t need an existing account or any prior access to obtain the certificates needed to carry out this trick. The advisory notes that presenting the server’s own certificate back to it grants access to its internal database gateway, while presenting another cluster member’s certificate grants internal cluster access and sidesteps authorization checks altogether.

Beyond Login: Trust Stores, Agents, and Access ScriptsThis is a different category of problem than the container-escape vulnerabilities previously reported in tools like runc, which focus on breaking out of an isolated workload. This flaw instead undermines the management layer that is supposed to control who gets into the environment in the first place.

The exposure extends further than simple login bypass. According to the Incus advisory, an attacker able to present the right public certificate can impersonate trusted client, metrics, or server identities; renew or delete entries in the trust store via self-service mechanisms; and compromise the authentication used for agent connections between host systems and the virtual machines they manage.

The bug also reaches into the “authorization scriptlet” — a customizable script some deployments use to make fine-grained access decisions. Because Incus passed the full, unverified certificate chain into this script, an attacker’s forged certificates could directly influence those access decisions. Deployments using token-based or OpenID Connect authentication aren’t automatically safe either, since clients using those methods can still present certificates during the handshake and trigger the same flawed check.

Fixes and Interim MitigationsIncus lists all versions prior to 7.6.0 as vulnerable, with 7.6.0 and later containing the fix. Canonical’s LXD advisory identifies patched releases at 4.0.15, 5.0.11, 5.21.9, and 6.10.1 across its respective release branches. Administrators should check their specific deployment against the relevant vendor advisory to confirm which branch and patch level applies.

Until an update can be applied, Incus recommends restricting access to the HTTPS management listener to trusted hosts only. Critically, there is no configuration change that fully resolves the underlying validation flaw — network-level restrictions reduce the attack surface but do not substitute for patching.

Identify every LXD and Incus deployment in your environment and check its version against the fixed releases above.

Apply vendor patches as a priority, treating internet-reachable management interfaces as especially urgent.

Restrict network access to HTTPS listeners to known, trusted hosts in the interim.

Review cluster membership and trust store entries for anything unexpected once patched.

Neither vendor advisory reports evidence of active exploitation at this time, but given the maximum severity rating and the fact that the flaw requires no password, stolen key, or user interaction, exposed management interfaces should be treated as a priority patching target.

Read Time:3 Minute, 33 Second

WatchGuard has published a sweeping security advisory covering 18 vulnerabilities across its Fireware OS and the Windows Mobile VPN with SSL client, with seven of those flaws rated critical and carrying CVSS scores between 9.1 and 9.5. The October 27, 2026 disclosure touches Firebox firewalls broadly, and several of the most severe bugs can be triggered by an attacker who hasn’t logged in at all.

The Headline Bug: A WireGuard Buffer OverflowThe single highest-rated issue, CVE-2026-103594, scores 9.5 on the CVSS scale and stems from a stack buffer overflow in how Fireware OS handles WireGuard VPN configuration, opening the door to remote code execution. The flaw affects Fireware OS versions 2026.2 up to (but not including) 2026.4, as well as the 12.12 branch prior to 12.12.4 — a wide enough range that most currently deployed Fireboxes using WireGuard are likely exposed until patched.

Pre-Authentication Flaws in Active Directory and SIP HandlingTwo additional critical bugs, CVE-2026-112709 and CVE-2026-112710, each carry a 9.2 score and involve heap buffer overflows in the firewall’s Active Directory authentication service. WatchGuard’s own advisory confirms that at least CVE-2026-112710 can be exploited for remote code execution before a user ever authenticates — meaning an attacker with network access to the service doesn’t need valid credentials to attempt exploitation. A related pre-authentication bug, CVE-2026-93857, also scored 9.2, affects the SIP proxy through a separate stack buffer overflow with the same remote code execution outcome. Rounding out the logging side, CVE-2026-103593 (9.1) is a stack buffer overflow in the firewall’s logging service that can likewise lead to code execution.

Root-Level Risk From Clustering and Access Portal BugsTwo more critical entries involve root-level exposure through different mechanisms. CVE-2026-93865, scored 9.2, is a missing-authentication flaw in the FireCluster synchronization daemon that WatchGuard says allows remote injection of root-level actions — a serious concern for any organization running Fireboxes in a clustered, high-availability configuration. CVE-2026-93866, also 9.2, is an integer overflow in the pre-authentication Access Portal that leads to an out-of-bounds memory write; WatchGuard’s advisory describes this as memory corruption rather than confirmed remote code execution, which is a meaningful distinction for teams prioritizing patch rollout.

The Seven Critical Flaws at a GlanceCVE-2026-103594 — CVSS 9.5 — WireGuard configuration — stack buffer overflow enabling remote code execution.

CVE-2026-112710 — CVSS 9.2 — Active Directory service — heap buffer overflow, pre-authentication remote code execution.

CVE-2026-112709 — CVSS 9.2 — Active Directory service — heap buffer overflow.

CVE-2026-93865 — CVSS 9.2 — FireCluster sync daemon — missing authentication, root-level action injection.

CVE-2026-93857 — CVSS 9.2 — SIP proxy — stack buffer overflow, pre-authentication remote code execution.

CVE-2026-93866 — CVSS 9.2 — Access Portal — integer overflow, out-of-bounds write.

CVE-2026-103593 — CVSS 9.1 — Logging service — stack buffer overflow enabling remote code execution.

Lower-Severity Bugs Still Worth WatchingBeyond the critical seven, two additional issues stand out for their potential impact despite lower scores. CVE-2026-90464 lets an already-authenticated attacker modify arbitrary files with root privileges because the affected component fails to validate commands properly, while CVE-2026-93864 allows a local attacker to overwrite arbitrary files as root by abusing a symlink-following flaw in firewalld. Neither requires remote, unauthenticated access, but both hand significant power to an attacker who has already gained a foothold.

Patch AvailabilityWatchGuard’s published fix guidance points to Fireware OS 2026.4 and 12.12.4 as the versions that resolve most of the listed issues, with T15 and T35 hardware requiring 12.5.22 specifically. The Windows Mobile VPN with SSL client’s separate credential-exposure issue is likewise resolved in the 2026.4 release. It’s worth noting this October disclosure is distinct from an earlier, separately tracked WatchGuard zero-day (CVE-2025-14733) that saw confirmed exploitation — there is no indication at this time that any of the 18 newly disclosed flaws have been exploited in the wild, though the combination of high severity and pre-authentication reachability makes rapid patching a priority for any organization running Firebox appliances.

Read Time:3 Minute, 53 Second

Three newly disclosed vulnerabilities in GoAhead, a compact embedded web server used across routers, printers, gateways, and industrial control equipment, could let attackers undermine the certificate checks that are supposed to keep encrypted device traffic trustworthy. GoAhead ships inside products from major vendors including Palo Alto Networks, Siemens, Honeywell, and Boeing, giving the flaws a reach that extends into hundreds of millions of deployed devices.

Certificate Trust at the Center of the ProblemAll three issues trace back to how GoAhead integrates with the TLS libraries responsible for verifying digital certificates during encrypted connections, including mutual TLS setups where both a client and a server must present valid credentials before communication proceeds. Security researchers at FoxIO, led by Sébastien Féry, reported the flaws privately in April 2026. GoAhead’s maintainers fixed all three in version 6.1.1, with advisories published on October 12.

Revoked Certificates That Still WorkThe most serious of the three, rated critical with a CVSS score of 9.1, affects builds that use an OpenSSL-compatible backend. GoAhead loads a Certificate Revocation List, the file that identifies certificates that should no longer be trusted, but never actually enables the setting that tells OpenSSL to check it. In testing, a client certificate that had already been revoked successfully completed a mutual TLS handshake, with the verification process reporting no error at any stage. Versions 3.4.5 through 6.1.0 are affected whenever a CRL is configured, though FoxIO noted the risk only materializes when an administrator has deliberately turned that feature on.

A Key Exchange Weakened to Eight PossibilitiesA second, medium-severity flaw affects the Mbed TLS backend. A buffer-length error truncates what should be a 2048-bit Diffie-Hellman key exchange value down to a single byte, which the server then transmits as the number 255 during the handshake. That leaves only eight possible shared-secret values, few enough that an eavesdropper who captures the traffic can simply try each one. In FoxIO’s own test, the correct value was recovered in five attempts. The exposure window is narrower than the certificate-revocation flaw, since it only applies to TLS 1.2 sessions using the DHE_RSA cipher suite with a client that does not reject undersized parameters; TLS 1.3 and ECDHE-based connections are unaffected, and the client used in testing rejected the broken value outright. Still, embedded or custom clients without strict parameter checks could unknowingly expose their traffic to passive decryption.

Certificate Chains Longer Than They Should BeThe third flaw, rated high with a CVSS score of 7.4, affects builds relying on an older LibreSSL verification path. GoAhead is designed to reject certificate chains deeper than ten links, but in testing, a chain of seventeen certificates rooted in a self-signed authority was accepted anyway, because LibreSSL reported a different kind of error that GoAhead’s logic let slip through when issuer checking was disabled. The same test against a newer LibreSSL release correctly rejected the oversized chain.

Why This Matters Beyond GoAhead ItselfThe disclosure lands amid a broader run of certificate-trust problems this month, including the exposure of private keys behind several intermediate certificate authority certificates in an unrelated incident, and separate scrutiny of embedded TLS libraries used across connected devices generally. Taken together, these cases underline a recurring theme: the cryptographic plumbing that device manufacturers rely on to establish trust is frequently assembled from third-party components that are not audited as rigorously as the headline product itself.

As FoxIO’s founder and CTO John Althouse pointed out publicly, a fix landing in the upstream GoAhead project does not automatically translate into a firmware update for any specific device; that depends entirely on individual manufacturers picking up and shipping the patched library.

Recommended Actions for Affected OrganizationsOperators running OpenSSL-compatible GoAhead builds between versions 3.4.5 and 6.1.0 should upgrade to 6.1.1 as soon as a vendor firmware update becomes available.

Mbed TLS users should upgrade, disable finite-field DHE cipher suites, or migrate to the OpenSSL backend.

LibreSSL users should enable strict issuer verification with a trusted certificate authority bundle, or move to a current LibreSSL release.

Security teams can use network fingerprinting tools, such as FoxIO’s JA4Scan, to identify which TLS backend a given GoAhead-based device is actually running.

Defenders should also review logs for use of the DHE cipher suites tied to the key-exchange flaw.

Because patch timelines depend heavily on individual device manufacturers, organizations operating GoAhead-based equipment, particularly in critical infrastructure environments, should proactively check with vendors about firmware update schedules rather than waiting for an automatic notification.

Read Time:3 Minute, 42 Second

Okta has disclosed a critical vulnerability in Okta Access Gateway (OAG) that allows an authenticated administrator to execute arbitrary system commands through the product’s Admin Console. The flaw, tracked as CVE-2026-115547, carries a CVSS v3.1 score of 9.1 and affects all OAG versions released before 2026.10.2.

A Flaw Rooted in Weak Input ValidationAccording to Okta’s advisory, published on October 22, 2026, the root cause is weak input validation in how the Admin Console processes specially crafted configuration values. Rather than treating administrator-supplied configuration data strictly as text, the affected code path can be manipulated into executing commands at the system level.

Okta classifies the bug under two well-known weakness categories: CWE-94, improper control of generation of code, and CWE-20, improper input validation. In practice, that means a value an administrator enters into a configuration field can be twisted into a command the underlying operating system actually runs.

Who Can Actually Exploit ItThe silver lining here is the access requirement. This is not an unauthenticated, internet-facing hole — an attacker needs administrative access to the OAG Admin Console before they can abuse the bug. Okta’s advisory does not describe any authentication bypass that would let a regular application account, or an anonymous attacker, reach the vulnerable code path.

That said, “needs admin access” is a lower bar than it sounds. Compromised administrator credentials, a phished session token, or an insider with console access would all satisfy the requirement. Once an attacker clears that threshold, the resulting command execution runs with the privileges of the OAG service account — not necessarily full root, but potentially broad enough to read sensitive configuration, pivot further into connected systems, or disrupt the gateway’s operation, depending on what that service account is permitted to do locally.

The CVSS vector underlines this balance: a network-based attack with low complexity, high privileges required, no user interaction, and a changed scope with high impact to confidentiality, integrity, and availability once triggered.

Not Okta’s First Access Gateway Fix This QuarterThis isn’t an isolated incident for the product line. The fix follows an earlier round of September patches for Okta Access Gateway and Auth0 that addressed authorization bypass, SQL injection, and stored cross-site scripting issues. Crucially, administrators who already applied that earlier Access Gateway 2026.9.1 update are not automatically protected — the September fixes addressed different vulnerabilities with different patched-version requirements, so 2026.9.1 does not satisfy this new advisory’s minimum fixed version of 2026.10.2.

Taken together, the pattern suggests OAG’s administrative surface has drawn sustained scrutiny recently, whether from internal review, external researchers, or both. Organizations that treat “we patched Okta last month” as a closed issue should check specifically against this new CVE.

What Defenders Should Do NowOkta’s guidance is straightforward: upgrade any Access Gateway deployment running a version earlier than 2026.10.2 to that release or later. No interim workaround is offered in the advisory, which puts the emphasis squarely on getting the patch deployed rather than mitigating in place.

Beyond the upgrade itself, security teams should treat this as a prompt to revisit who actually holds administrative rights on the OAG console. Because exploitation depends entirely on administrative access, tightening that access list, enforcing strong multi-factor authentication on admin accounts, and auditing recent configuration changes for anything unexpected are all reasonable complementary steps. Logging and monitoring around the Admin Console should also get a second look, since the advisory does not detail exactly which configuration field is involved, making it harder to write a narrowly targeted detection rule.

It is worth remembering that privileged-session abuse has bitten Okta customers before in unrelated incidents, underscoring why administrative access to identity infrastructure deserves outsized protection regardless of the specific CVE involved.

No Known Exploitation — YetOkta’s advisory does not report any evidence of active exploitation in the wild, nor has public proof-of-concept code surfaced. The absence of reported attacks is good news, but it is not a guarantee: the vulnerability has only just become public, and threat actors frequently work backward from a patch diff or advisory details to build a working exploit within days of disclosure.

Given the severity score and the sensitivity of identity-gateway infrastructure, security teams should prioritize this update over routine patch cycles and keep an eye on Okta’s advisory portal for any updates as more details emerge.

Read Time:3 Minute, 58 Second

Palo Alto Networks has confirmed that a pair of critical remote-code-execution flaws in the PHP language runtime extend into its own PAN-OS firewall software and Panorama management platform, and that fixes won’t be fully available for roughly a week after the advisory update.

The two issues, tracked as CVE-2026-109618 and CVE-2026-109619, stem from how PHP handles severe internal errors through a function called longjmp(), which abruptly jumps program execution back to an earlier saved checkpoint. When that jump happens at the wrong moment, it can leave stale or uninitialized memory behind — memory that a later part of the program may then act on, opening a path for an attacker to run their own code.

Two Related but Distinct FlawsCVE-2026-109618 is triggered when the server runs out of memory partway through handling a request, leaving that request’s memory in an incomplete state. If cleanup routines later operate on that incomplete memory, an attacker who can reliably force memory exhaustion may be able to turn the resulting instability into remote code execution.

CVE-2026-109619 is a related but separate issue involving global memory references that continue pointing at memory after it has already been freed. A subsequent request that reads or acts on one of those dangling references can again give an attacker a route to execute arbitrary code.

Both flaws trace back to the broader PHP vulnerability research effort published under the name “PHP2Shell,” which carries a CVSS v4.0 base score of 9.2. Palo Alto has assessed its own product-specific exposure slightly lower, at 8.7, and notes that for its products the primarily affected security property is availability rather than confirmed data theft or configuration tampering — though the company is careful to frame that as the current assessment, not a guarantee against more severe impact.

Scope: Management Interfaces, Not GlobalProtectAccording to the updated advisory, the vulnerable surface is limited to PAN-OS management interfaces — the HTTPS administrative console and the XML API — rather than the data-plane components most organizations expose to end users. A dataplane interface is only affected if it has a management profile explicitly attached to it. Notably, GlobalProtect portals and gateways, Clientless VPN, and Captive Portal are all listed as unaffected, which should reduce panic for organizations whose remote-access infrastructure runs through those services.

Affected branches span a wide swath of PAN-OS releases, including 10.2, 11.1, 11.2, 12.1, and 12.2, running on PA-Series and VM-Series firewalls, as well as Panorama (including virtual and M-Series deployments). No unusual configuration is required to be vulnerable — any device on an affected branch with its management interface reachable is a candidate for exploitation.

Two cloud-delivered products, Cortex XCORE SaaS and WildFire Cloud, were also affected but have already received fixes, delivered on October 21 and October 22 respectively. Cloud NGFW, Cortex XDR, Cortex XSIAM, Prisma Cloud, Prisma Access, and the GlobalProtect App are all currently listed as unaffected by this issue.

Patches Are Still ComingAs of the October 24 advisory update, Palo Alto said it has no evidence of malicious exploitation against its own products — but that comes with an important caveat: security researchers at Unit 42 have already observed proof-of-concept exploit code circulating for the broader PHP2Shell vulnerabilities, meaning the gap between disclosure and active abuse could close quickly.

Firmware fixes are still on a rolling schedule rather than available today. The earliest hotfixes — versions 10.2.18-h13, 11.1.16-h4, and 11.2.10-h16 — are estimated for October 26, with PAN-OS 12.2.4-h1 targeted for October 28 and additional hotfixes planned through October 30. Palo Alto has emphasized that these dates are estimates and may shift.

What Administrators Should Do NowRestrict access to PAN-OS and Panorama management interfaces to trusted internal IP ranges or a dedicated jump host — internet-facing management interfaces represent the highest-risk configuration.

Where possible, enable Threat Prevention coverage for this issue, which Palo Alto has tied to signature 543004 and subsequent content updates (versions 9162 through 9164 and later). Doing so requires routing management traffic through a dataplane port, configuring an inbound certificate, and enabling HTTPS decryption and inspection.

Track each affected device’s specific hotfix path against Palo Alto’s advisory and Unit 42’s threat brief, since release timing varies by branch.

Treat access restrictions as a stopgap, not a substitute for installing the fixed release once it becomes available for each platform.

The disclosure is a reminder that vulnerabilities in widely used runtimes like PHP don’t stay contained to web applications — they can resurface inside the management stacks of the very security appliances organizations rely on to keep attackers out.

Read Time:3 Minute, 9 Second

The PHP security team has issued advance warning of two critical vulnerabilities and scheduled an unusual coordinated security release for October 21, 2026, at 14:00 UTC. Both issues carry a CVSS 4.0 score of 9.2, giving hosting companies, application owners and incident-response teams only a short preparation window before technical details and patched builds become public.

PHP’s notice says the release could arrive earlier if information about either flaw leaks further or if defenders identify active exploitation. The project has not yet published the complete affected-version matrix, prerequisites or attack mechanics. That limited disclosure is deliberate: it gives operators time to prepare without providing attackers with a roadmap before fixes are available.

Remote code execution is reported, but details remain limitedPublic reporting associates the flaws with CVE-2026-109618 and CVE-2026-109619. Security firm watchTowr and an advisory from CERT-EU describe possible unauthenticated remote code execution, an outcome that could let an external attacker run chosen commands on a vulnerable web server. However, PHP’s own advance notification does not name those identifiers or confirm precisely how exploitation would work.

Claims that every PHP release from version 5 onward is affected have also not been confirmed by the vendor. It remains unknown whether default installations are exposed, whether a particular extension or setting is necessary, and whether behavior differs across operating systems. Administrators should therefore avoid treating speculative configuration advice as a substitute for the official release notes.

The published vendor rating is 9.2 under CVSS 4.0, not the maximum 10.0 score seen in some early discussion. That distinction does not make the flaws routine: PHP powers a vast range of public websites, content-management systems and business applications, so a remotely reachable vulnerability can create a large patching race even when exploitation requires specific conditions.

No confirmed attacks at the time of warningAt the time of the advance notice, watchTowr reported no known exploitation in the wild. PHP’s willingness to accelerate the release is a precaution and should not be read as proof that systems have already been attacked. Likewise, leaked demonstrations or proof-of-concept claims do not by themselves establish successful intrusions against real organizations.

Past PHP incidents explain the urgency. Attempts to exploit CVE-2024-4577 were observed within roughly a day of its disclosure. That older issue is separate from the new pair, as are PHP SOAP extension vulnerabilities fixed earlier in 2026, but both examples show how quickly public technical information can be operationalized.

Prepare the deployment pipeline nowTeams do not need to wait for exploit details to reduce response time. They can identify the owners, dependencies and update path for every PHP runtime before fixed packages land.

Inventory internet-facing servers, containers, appliances and managed applications that embed PHP.

Confirm which team or hosting provider controls each runtime and how version changes reach production.

Prepare backups, rollback procedures and a small representative test set for urgent validation.

Monitor the official PHP release channel for the affected-version list and fixed builds.

Where rapid patching is impossible, assess whether exposed applications can be temporarily isolated without unacceptable business impact.

After deploying the update, administrators should verify the version used by the running web service rather than trusting a package-manager result alone. Multiple PHP installations, stale containers or a service that was not restarted can leave the vulnerable interpreter active. External scanning and application health checks can help confirm that the intended build is serving requests.

Until the advisory is complete, the most useful response is disciplined readiness: avoid guessing about immunity, document exceptions, and prioritize publicly reachable systems. Once PHP releases authoritative details, defenders can refine exposure assessments and detection rules using facts instead of early claims.