Mozilla said on 20 October 2026 that on 17 October at 20:06 UTC (18 Oct 04:06 Perth) a community member reported that the private keys behind eight intermediate certificates of Indian certificate authority eMudhra had been compromised, which would let an attacker issue HTTPS certificates for sites they do not control. Firefox blocked the certificates through OneCRL by 22:59 UTC the same day without needing an update, and Mozilla is now shipping an NSS trust-store update that removes the root that signed them, which will break some non-Firefox clients until affected servers move to new chains. The Chrome Root Program said it got the same report from a researcher at 18:05 UTC on 17 October and pushed a CRLSet block on the public keys of the six TLS-issuing intermediates at 19:45 UTC, which also covers Sectigo cross-certificates that share those keys; the two code-signing intermediates cannot be used for TLS in Chrome. Chrome says no TLS certificates chaining to the six intermediates were in Certificate Transparency logs before the block, so no fraudulent certificate could have been trusted by default in Chrome or other CT-enforcing browsers. Chrome Root Store version 43 will drop the upstream eMudhra root, and Chrome is reviewing eMudhra's remaining CA certificate. Mozilla says it does not believe other CAs are affected and has not said how the keys were exposed; eMudhra's responses are posted in Mozilla's incident bug (see the 21 October update), and it has since published a statement on its website (first published 20 October, updated 21 October; see the update below). Separately, Go released 1.27.3 and 1.26.10 on its URGENT security track (CVE-2026-111943, Go issue 82345): crypto/x509 now drops any chain through the eight keys, matched by public-key hash so cross-signed copies are caught too, including on the macOS and Windows platform verifiers. There is no switch to turn it off, and it also bites private deployments that deliberately trust those keys. Go clients only get the block once rebuilt on a fixed release, since Go's verifier does no revocation checking. (sources: Mozilla dev-security-policy; Go issue 82345 on GitHub) UPDATE (20 Oct, Mozilla Security Blog): Mozilla released Firefox 158.0.1 for desktop and Android, Firefox ESR 115.43.1 and Firefox ESR 153.5.1 to deliver the block to the minority of users whose custom settings stopped the OneCRL update, and NSS 3.131.1, which removes the root that signed the affected intermediates from Mozilla's trust store for other applications that use it or lists derived from it. UPDATE (20–21 Oct): Mozilla's Dennis Jackson told trust-store maintainers on 19 October (oss-security, posted 20 Oct) that six of the eight intermediates are for TLS and two for code signing, that eMudhra revoked them on 18 October and Sectigo revoked its cross-certificates on 19 October, and that clients which do not check revocation, or fail open, need a trust-store update; he warned abuse of the keys is likely in the near future and that no certificates from them had appeared in Certificate Transparency logs. A disclosure site he maintains (emudhra.we-have-a-problem.com) says the reporter, 'Wayne', proved the compromise on 17 October by signing a message with each key, and that Apple devices have blocked the certificates since 19 October. Cyber Kendra reports Microsoft blocked them on 20 October; Microsoft had not published its own notice as of 21 October. The site tracks downstream fixes: Ubuntu ca-certificates 20260816ubuntu0.22.04.1/24.04.1/26.04.1/26.10.1, Alpine ca-certificates 20261020-r0, Arch ca-certificates-mozilla 3.131.1-1, Gentoo, Chainguard, the curl CA bundle of 2026-10-20, Python certifi 2026.10.19, pip 26.2.2, uv 0.13.4, Rust rustls-webpki 0.103.16 and webpki-roots 1.0.10, Electron 44.9.1, 43.8.1 and 42.11.16, Composer ca-bundle 1.4.16 and 1.6.0 and Elixir castore 1.0.22; Debian, Fedora, FreeBSD, Node.js and Bun were still pending. It also warns that macOS's built-in curl checks /etc/ssl/cert.pem without revocation, and that file has not been updated. UPDATE (21 Oct; Mozilla Bugzilla incident 2083449 and the disclosure site): the cause is flawed key generation, not theft. Mozilla's Dennis Jackson found the eight P-384 private keys were all integers smaller than 256, so anyone can recover them almost instantly from the public certificates; Mozilla recovered them independently on 17 October without knowing the reporter's method, and says several other people have since done the same, at least one publicly. The keys came from a 30 April 2025 key ceremony, so the weakness has existed since then; no certificates from them appeared in Certificate Transparency logs in that period, so CT-enforcing browsers (Firefox, Chrome, Edge, Safari) could not have been attacked, but it is unknown whether clients that do not enforce CT were. eMudhra said in the bug (19 Oct) that the keys were made on Utimaco HSMs during an approved deviation to test key wrap and unwrap for export to its US and European data centres, that a script flaw created a second, weak set of keys, and that these were used by mistake to make the certificate requests because the key labels were similar, including the requests sent to Sectigo for cross-signing. It says only EM DV TLS CA - G3C was in production and no end-entity certificates were issued from the eight; its RSA intermediates and India-only A-series keys (Entrust HSMs) are not affected; and it will re-check every key ceremony over the next week. On 20 October Mozilla began an emergency removal of trust in emSign ECC Root CA - G3 (not emSign Root CA - G1), and Chrome committed to the same. eMudhra stopped issuing from all intermediates under the G3 ECC root that day and said about 30,000 certificates, about 97% issued via ACME, must move to chains under its RSA root G1. Sectigo completed revocation of its cross-certificates on 19 October. Debian (20250419~deb12u2, 20250419+deb13u1, 20260816+nmu1) and Fedora (2026.2.92_v9.0.319) have now shipped ca-certificates fixes, and the disclosure site gives a manual workaround for FreeBSD 14 and later; FreeBSD packages, Node.js and Bun were still pending. UPDATE (21 Oct; Cloudflare blog and disclosure site): Cloudflare says it learned of the compromise at about 17:00 UTC on 19 October, patched critical services before public disclosure and has found no active exploitation on its services. It has shipped fixed Cloudflare One / WARP clients (Android 2.5.6, iOS 1.12.16, Windows, macOS and Linux 2026.8.2115.0), 1.1.1.1 app (Android 6.38.10, iOS 6.31.7) and Cloudflare Tunnel (cloudflared) 2026.10.2, and deployed mitigations across its CDN, Developer and Zero Trust products; Gateway users with current clients are protected. Customers must still review mutual TLS trust stores used to verify client certificates, origin certificates and server settings in Full (strict) mode, and container images, and Cloudflare warns that updating an SDK may not change the trust store an HTTP library or runtime actually uses, and that errors should not be fixed by turning off verification. The disclosure site now says Microsoft platforms have blocked the certificates since 20 October, and lists Cloudflare CFSSL trust store 2026.10.1 and Perl Mozilla::CA 20261020 as fixed. UPDATE (21 Oct, evening Perth): Node.js's 21 October security releases (26.12.1, 24.22.1, 22.23.4) include a CA-certificate update for the eMudhra intermediate CA compromise on all three lines (see Cyberstack's Node.js card). UPDATE (21 Oct, eMudhra statement): eMudhra's statement on its website, last updated 21 October, says an independent security researcher reported on 18 October that the keys of eight of its Global TLS intermediate CAs were cryptographically weak, and that it revoked all eight the following day. eMudhra says no certificates had been issued from any of them, its infrastructure was not compromised and no data was breached, seven of the eight were never used in production, and the browser root programs distrusted its ECC root as a precaution. It says the keys were generated on FIPS 140-2 Level 3 certified HSMs and that a key wrap/unwrap step in the April 2025 ceremony produced a second, weak set of keys, which were the ones published to the browser root stores; it says it has not yet confirmed the exact root cause and is not aware of any evidence that the weak keys were recovered or exploited by anyone before the issue was disclosed. eMudhra says the impact is limited to TLS certificates chaining to the distrusted ECC root and contained to a single customer ecosystem in the United States, which it is moving to certificates from an alternate, independently operated, publicly trusted CA hierarchy, and that its digital signature and eSign services, emSigner, CertiNext, emCA, Privatrust and SecurePass are not affected. UPDATE (22 Oct, eMudhra press release): eMudhra announced on 22 October that its board has decided to voluntarily withdraw from the global SSL/TLS certificate business. Chairman V. Srinivasan said global SSL/TLS contributes about 1% of eMudhra's global revenue, that the company revoked the affected CAs within 14 hours of discovery, that no end-entity certificates were issued from them, and that its infrastructure was not compromised and no data was breached. eMudhra says its G1 RSA roots will keep serving customers until the transition is complete, it will contact affected customers to replace certificates free of cost from partners, revocation and status services will run until every issued certificate has expired or been replaced, and it will deliver a full root-cause report to the browser root programs; it gave no exit date and did not name the partners. It says its digital signature certificate, eSign, emCA, CertiNext, emSigner, SecurePass and emAS services are not affected. Google's security blog says the removal of emSign ECC Root CA - G3 from the Chrome Root Store is expected to reach all devices relying on it on Tuesday morning, 27 October 2026 (US Pacific time), and that website operators with certificates chaining to that root must immediately get a new TLS certificate from another hierarchy in the Chrome Root Store. UPDATE (21–22 Oct; Mozilla Bugzilla incident 2083449): the Chrome Root Program posted 12 questions to eMudhra on 21 October (20:38 UTC, 22 Oct 04:38 Perth). It says that, based on Certificate Transparency data as of 21 October, about 30,800 unexpired precertificates chain to emSign ECC Root CA - G3, and 30,791 of them (99.9%) were issued by two Internet2 / InCommon subordinate CAs (InCommon Intermediate CA - OVG3C, 23,806; DVG3C, 6,985), with 18 from eMudhra's own intermediates. Chrome asks how ACME subscribers will actually be renewed before Chrome Root Store v43 lands (expected in Stable on 27 October 2026, US Pacific time), for per-CA migration figures and a completion date, and why eMudhra's June 2025 report on mis-signed CRLs (Bug 1970728) did not disclose that two key pairs existed for the affected CAs; it says that disclosure 'raises serious concerns regarding eMudhra's transparency and incident handling'. Chrome also asks which private key signed CRL #11 for emSign Root TLS CA - G1, published on 14 October 2026 with a signature that does not verify against that root or any disclosed 4096-bit RSA CA key, and whether multiple key pairs exist for any eMudhra root. eMudhra had not replied in the bug as of the latest comment checked (22 Oct 13:31 UTC, 21:31 Perth). Separately, Mozilla's Dennis Jackson said on 21 October that some Firefox for Android profiles were not applying the updated blocklist at startup and that Firefox for Android 158.0.2 fixes this. UPDATE (24 Oct 2026; Mozilla Bugzilla incident 2083449): an eMudhra representative (signing as Naveen, from an eMudhra address) replied in the bug on 23 October at 11:00 UTC (7:00 pm Perth), saying intense social media scrutiny and analysis by investors and customers over the last few days had made any meaningful analysis of the event 'pretty much impossible', that the event happened on 30 April 2025, that eMudhra has a lot of digging to do before it can share a meaningful report, and that it will uphold its disclosure obligations to the community. The Chrome Root Program replied at 14:16 UTC that social media scrutiny and analysis by investors or customers 'are not acceptable explanations for delayed responses here', and said it expects eMudhra to prioritise its review of the issue and its security response. Mozilla's Dennis Jackson said at 14:35 UTC that the Mozilla Root Program sent its own questions to eMudhra on 20 October at 20:31 UTC with a 24-hour deadline for an initial response, that eMudhra asked for a further 24 hours after the deadline passed on 21 October, and that as of 23 October Mozilla had not received a response. (source: Mozilla Bugzilla) UPDATE (24 Oct 2026; Red Hat): Red Hat tracks the issue as CVE-2026-114406, which it rates Critical (CVSS 3.1 6.8), and says that because not every client using the system CA store can distrust only specific intermediate certificates, it is removing the root CA certificates of the authorities that signed the weak intermediates. Red Hat has shipped ca-certificates 2026.2.92_v9.0.319 for Red Hat Enterprise Linux 10, 9 and 8 (RHSA-2026:88455, RHSA-2026:88459, 22 Oct; RHSA-2026:88550, 23 Oct) and for RHEL 7 Extended Lifecycle Support, several Extended Update Support, Update Services for SAP Solutions and Advanced Mission Critical streams, and Red Hat Hardened Images; as of 24 October it still lists Red Hat Enterprise Linux 6, OpenShift Container Platform 4 (RHCOS images) and OpenShift GitOps images as affected, with no fix listed. (source: Red Hat) UPDATE (24 Oct 2026; MongoDB): MongoDB, as the CVE numbering authority, says MongoDB Compass before 1.53.1 trusts certificates issued by the recoverable eMudhra intermediate CAs because the TLS root store in its bundled Electron runtime contains them (CVE-2026-115929, CVSS 4.0 7.6), and that Compass 1.53.1, released on 23 October with Electron 44.9.1, resolves it. (source: MongoDB) UPDATE (25 Oct 2026; Python): CPython has added a small denylist to its ssl module that rejects any certificate chain containing one of the compromised eMudhra intermediate keys, whatever the SSLContext settings, when certificate verification is on (CERT_NONE is unaffected); the change is tracked as CVE-2026-115557, which the Python Software Foundation rates CVSS 4.0 9.4 (Critical). The fix was merged into CPython's main branch and its 3.15, 3.14, 3.13, 3.12 and 3.11 branches on 24 October (UTC). The newest releases on python.org's downloads page as of 25 October, 3.15.1 and 3.14.9, are dated 21 October, before the fix was merged. In the issue, its author, CPython team member tiran, asked Python's release managers on 24 October to ship security releases of Python 3.13 to 3.15 with the fix as soon as possible. (source: CPython GitHub issue #160040; CVE-2026-115557 record on cve.org) Correction (26 Oct 2026): An update describing Oracle's Java Security Alerts has been removed because Oracle's pages cannot be read by Cyberstack and no readable outlet has reported Oracle's Java changes. The distrust of the eMudhra certificates on this card rests on Mozilla, Google's Chrome Root Program, Go and Red Hat, all linked. (source: Mozilla; Google; Go issue 82345 on GitHub; Red Hat) Correction (26 Oct 2026): the CVE-2026-115557 link now points to the official CVE record on cve.org instead of a third-party copy on CVE.report. (source: CVE-2026-115557 record on cve.org) UPDATE (25 Oct 2026; Python): python.org has released Python 3.15.2, 3.14.10 and 3.13.18, each dated 25 October. The 3.15.2 release notes describe it as an expedited security release to address the compromised eMudhra intermediate CA keys, say the keys are now blocked by the ssl module as a last resort and list CVE-2026-115557 (gh-160040). Python says normal uses of pip, including upgrading pip itself, are now safe from attacks based on those keys even if pip has not been updated. (source: Python.org) Correction (27 Oct 2026): only the Python 3.15.2 release notes use the words "expedited security release"; an earlier version applied them to all three releases. (source: Python.org) UPDATE (25 Oct 2026; Python): python.org also released Python 3.12.16 and 3.11.18 for the legacy 3.12 and 3.11 series, both dated 25 October, and both list CVE-2026-115557 (gh-160040), the ssl-module block on the compromised eMudhra intermediate CA keys, among their security content. The 3.12.16 page calls it an expedited security release, and both releases are source-only, with no installers. (source: Python.org) UPDATE (27 Oct 2026; Microsoft): Microsoft has published its response to the compromised eMudhra keys on the MSRC blog, dated 26 October. It says the issue involves eight eMudhra intermediate CA private keys, six associated with TLS and two with code signing, and "was not a compromise of Microsoft systems". Microsoft says it published an update to the Windows Disallowed Certificate Trust List on 20 October to block the affected certificate authorities and deployed a separate CRLSet update for Microsoft Edge and WebView2 that is delivered automatically. On 26 October it released an out-of-band Windows update that removes seven certificates associated with the affected hierarchies (six eMudhra G3 roots and an AAA Certificate Services cross-sign) from the Windows trust list, and it plans to remove the same seven from the Microsoft Edge trust list on 27 October. Microsoft advises letting automatic certificate trust and Edge component updates reach devices, making sure disconnected Windows devices receive the updated lists, and replacing any certificates that chain to the seven removed certificates. Microsoft's Windows 11 update history lists the 26 October out-of-band update as KB5134133. (source: Microsoft) UPDATE (31 Oct 2026; JetBrains): In a security blog post dated 30 October 2026, JetBrains tells users to update its IDEs, ReSharper, .NET tools, Toolbox App and Gateway because of the compromised eMudhra certificates. It says the IDEs, Toolbox App, Gateway and ReSharper are affected through the trust store in the JetBrains Runtime (JBR), the JCEF embedded browser is also affected, and operating system updates do not protect against the issue. JetBrains says it has integrated Oracle’s fixes for CVE-2026-91403 and CVE-2026-114820 into JBR (builds including jbr25.635.79, jbr25.508.41, jbr25.329.142, jbr21.1163.125 and jbr21.1038.91), applied Chrome’s certificate updates to JCEF (CVE-2026-118696) and fixed jetbrainsd in version 0.9.9728 (CVE-2026-118697). Fixed IntelliJ IDEA versions include 2026.3 RC, 2026.2.4, 2026.1.5.1, 2025.3.6.2 and 2025.2.6.4; Toolbox App users should move to 3.9.1 or 3.8.2 and Gateway users to 2026.1.4, 2025.3.3 or 2025.2.6. Versions 2025.1 and earlier, and Toolbox App 3.7 and earlier, get no fix. JetBrains says that at the time of publishing it was not aware of any exploitation of this issue against JetBrains users. (source: JetBrains) UPDATE (1 Nov 2026): Red Hat's CVE page for CVE-2026-114406 now says the CVE has been assigned to track trust store updates to distrust compromised certificates and is not a vulnerability, pointing to bulletin RHSB-2026-012; its VEX file (current version 31 October, 23:06 UTC; 7:06 am Perth, 1 November) still rates the impact Critical. The VEX file now lists fixed ca-certificates for Red Hat Enterprise Linux 6 Extended Lifecycle Support (RHSA-2026:90985, released 4:19 am Perth, 28 October) and RHEL CoreOS fixes for OpenShift Container Platform 4.12, 4.14, 4.16 and 4.18 to 4.22 (errata released between 8:02 pm Perth on 27 October and 6:03 am Perth on 28 October), and lists Red Hat AI Inference Server, Red Hat Enterprise Linux AI 3, Red Hat OpenShift AI, OpenShift Container Platform 5 and OpenShift GitOps as known affected, with no fix listed. (source: Red Hat) Correction (02 Nov 2026): removed The Hacker News as a source; removed details no other source gives. (source: Mozilla; Go issue 82345 on GitHub)
Mozilla dev-security-policy — Compromised eMudhra Intermediate Certificates (Mozilla, 20 Oct 2026; Chrome Root Program reply same day)
French pentest firm Mobeta published a technical write-up on 20 October 2026 of an unauthenticated SQL injection in GLPI, the widely used open-source IT asset management and helpdesk platform. Sending both the genical and checkavailability parameters to front/planning.php skips the iCalendar token check, and the begin and end dates then reach a hand-built QueryExpression in the not-planned branch of CommonITILTask::genericPopulatePlanning() (the same pattern exists in ProjectTask) without escaping. An unauthenticated attacker can extract the full database with a time-based blind injection, including password hashes, configuration, inventory, tickets, projects and users; Mobeta says this can lead to administrator takeover and, depending on version, code execution. GLPI 11.0.8 and earlier 11.x releases are exploitable; GLPI 10.x has the same code but global input escaping blocks it; on the GLPI 12 development branch Mobeta examined, the bug would expose admin session IDs in clear text. Mobeta reported it on 3 August and GLPI fixed it in 11.0.9 on 16 September; GLPI published advisory GHSA-753w-2942-4pxm on 26 October, rating the flaw High (CVSS 4.0 8.7) and listing no CVE (as of 29 October). GLPI's 7 October advisories fixed further planning-feature flaws (missing authorisation and user-name enumeration) in 11.0.10 and 10.0.28. No in-the-wild exploitation has been reported, but the write-up includes working request examples. (source: Mobeta) Correction (29 Oct 2026): the card said GLPI's advisory GHSA-753w-2942-4pxm was not yet published and that 11.0.10 and 10.0.28 were the latest releases; GLPI published the advisory on 26 October (High, CVSS 4.0 8.7, no CVE listed) and released 11.0.12 and 12.0.1 on 28 October, and GLPI 12.0.0 was released on 7 October, so the 12 branch is no longer described as unreleased. (source: GLPI on GitHub) Correction (02 Nov 2026): removed talkback.sh as a source. (source: Mobeta; GLPI on GitHub)
Mobeta — Unauthenticated SQL injection in GLPI (≤ 11.0.8) (20 Oct 2026)
The Bytecode Alliance's Wasmtime maintainers published two critical advisories on 19 October 2026 for sandbox escapes in Cranelift, Wasmtime's default compiler backend, each rated CVSS 9.9. CVE-2026-115889 (GHSA-897f-g5gm-fmxm): in Wasmtime before v43, Cranelift bit-packs its SSA value indices in a way that can silently overflow in release builds and cause arbitrary miscompilation; the advisory says a very large Wasm function body, or one crafted to use many SSA values, can use this to force type confusion and escape the sandbox, on any architecture with default settings. Affected: before 36.0.19, and 37.0.0 up to (not including) 43.0.0; fixed in 36.0.19, and Cranelift was changed in v43 so later versions are not susceptible. CVE-2026-115893 (GHSA-mghf-wjfp-p5xm): on aarch64, Cranelift can compile a Wasm br_table instruction with more than about 256k targets into a conditional branch with the wrong target; the advisory says any Wasmtime engine on aarch64 with default settings can be forced to jump to arbitrary code by a user-controlled Wasm module, and that every version supporting aarch64 since that support was added in 2020 is affected. Fixed in 36.0.19, 48.0.7 and 49.0.4 (all released 19 October); Wasmtime 50.0.0 (released 20 October) includes the same br_table fix in its release notes. (sources: Wasmtime advisories GHSA-897f-g5gm-fmxm and GHSA-mghf-wjfp-p5xm; Wasmtime 50.0.0 release on GitHub) Correction (02 Nov 2026): removed The Hacker News as a source; removed details no other source gives. (source: Wasmtime advisories on GitHub)
Wasmtime advisory GHSA-mghf-wjfp-p5xm — Cranelift backend on aarch64 can jump to incorrect target on large Wasm `br_table` instruction (19 Oct 2026)
Laravel published advisory GHSA-f9x3-7vq9-cph6 (CVE-2026-114509) for laravel/framework on 19 October 2026. Laravel says its built-in TokenGuard, when configured with a standard token-based API guard, may be bypassed to authenticate as an arbitrary existing user without knowledge of their valid API token: under certain database configurations (MySQL/MariaDB) an attacker can submit a specially crafted, non-string credential value that is mishandled during the authentication lookup, so the query matches an unintended user record instead of failing. Laravel says an unauthenticated attacker may authenticate as another user, leading to authentication bypass and account takeover on any route protected by the affected guard. The advisory rates it Critical, CVSS 4.0 9.2, lists affected versions as below 13.29.0 and below 12.68.0, patched in 13.29.0 and 12.68.0, and credits KIKOmanasijev as reporter. No exploitation has been reported. Source: Laravel GitHub security advisory GHSA-f9x3-7vq9-cph6 (19 Oct 2026). Correction (02 Nov 2026): removed The Hacker News as a source. (source: Laravel)
Laravel — GHSA-f9x3-7vq9-cph6: Token-based API guard Auth Bypass (19 Oct 2026)
Rapid7 disclosed three vulnerabilities in Eptura Archibus on 19 October 2026, found by Rapid7 security consultant Marcus Chang during continuous red-teaming through its Vector Command service. Rapid7 says a legacy API endpoint in the Archibus Web Central application, which uses Java Direct Web Remoting (DWR), can be abused to bypass authentication and run workflow functions without logging in (CVE-2026-107186, CVSS 8.6 High); the most serious of those functions allow full database read, including user names and passwords (CVE-2026-107187, CVSS 8.5 High), and an insecure file upload that leads to remote code execution (CVE-2026-107188, CVSS 9.6 Critical). Rapid7 says a malicious actor with HTTP network access to the server can read secrets and passwords out of the database and run system commands as NT AUTHORITY\Local Service. Rapid7 says users should update Archibus to version 2025.02 or higher, in which the vulnerable DWR method used for the bypass was moved to a REST API, with the installer available through an Eptura account. Rapid7's disclosure timeline says it first contacted Eptura on 2 July, that Eptura replied on 9 October clarifying impacted versions and saying a fix was in development for version 2025.01, and that disclosure was moved to 19 October at Eptura's request. Rapid7's post does not include an Eptura statement and does not list exact affected versions. No exploitation outside Rapid7's authorised testing has been reported. Source: Rapid7 blog (19 Oct 2026).
Rapid7 — Authentication Bypass, Remote Code Execution, and Database Read in Eptura Archibus (FIXED) (19 Oct 2026)
Pillar Security said on 19 October 2026 that it found a critical remote code execution flaw in opencode, Anomaly's open-source AI coding agent, affecting Windows and Windows Subsystem for Linux (WSL): an attacker-controlled remote Model Context Protocol (MCP) server can execute arbitrary code on a developer's machine during a remote MCP OAuth authentication process, without additional user interaction or consent. Pillar says the MCP server supplies the OAuth authorization_endpoint, which opencode passed to the open package (open@10.1.2); on Windows that package builds a PowerShell command without escaping the target, so a PowerShell subexpression carried inside an ordinary https:// URL runs. Pillar says the server did not need to be malicious when configured: a later compromise, hijacked registry entry, typosquat or expired domain could trigger the same path. Pillar lists opencode (opencode-ai on npm) versions 1.0.137 to 1.18.32 on Windows and WSL as affected and says macOS and Linux are not affected; it says the fix shipped in 1.18.33, which GitHub shows was released on 28 September 2026. Pillar says the fix (pull request #51414, merged 25 September) bumped open to 11.0.4 and added http/https scheme checks, but that scheme validation alone would not have stopped its payload and the dependency bump is what closed the hole. Pillar says Anomaly did not issue a security advisory or request a CVE, shipped the fix as a refactor, and told Pillar that malicious MCP servers are outside its threat model; opencode's GitHub security policy says external MCP servers a user configures are outside its trust boundary. Pillar rates the flaw critical with a proposed CVSS 3.1 score of 9.8, and notes that without a CVE, vulnerability scanners and dependency alerts will not flag affected installs. (sources: Pillar Security; opencode v1.18.33 release on GitHub) Correction (02 Nov 2026): removed The Hacker News as a source; removed details no other source gives. (source: Pillar Security; opencode release on GitHub)
Pillar Security — Open and Shut: Remote Code Execution in opencode via MCP OAuth (19 Oct 2026)
Siemens ProductCERT said on 19 October 2026 that it has confirmed active exploitation of CVE-2026-110936, a DLL sideloading flaw in Siemens Software Center (the installer and update manager for Siemens software) that it fixed in version 4.0.9.8 and disclosed in advisory SSA-580366 on 15 October. The app loaded helper DLLs from its own folder without checking them, so attackers shipped a genuine, validly signed copy of version 3.5.8.7 alongside their own archive.dll inside an installer called AllMyBasic.msi; msiexec.exe installs it under AppData\Local\Programs and starts SiemensSoftwareCenter.exe, which loads the attacker DLL. Siemens says the Siemens program itself was not modified and no Siemens system, product or update channel was breached, and it is sharing indicators with EDR vendors and authorities. The victims are lured by ClickFix pages that get them to paste a PowerShell command. The payload is a remote access trojan. Siemens rates the flaw CVSS 3.1 6.7 and CVSS 4.0 8.4 because it needs local access, but in this campaign the attackers bring the vulnerable signed copy with them, so PCs that never had Siemens software are also at risk. Canada's Cyber Centre issued AV26-1063. (source: Siemens ProductCERT) UPDATE (22 Oct 2026): CISA added CVE-2026-110936 to its Known Exploited Vulnerabilities catalog on 20 October 2026, with a 3 November due date for US federal agencies. (source: CISA KEV catalog) Correction (02 Nov 2026): removed The Hacker News as a source; removed details no other source gives. (source: Siemens)
Siemens ProductCERT — Active exploitation of CVE-2026-110936 in Siemens Software Center (19 Oct 2026)
Roundcube published security updates 1.6.20 (1.6 LTS) and 1.7.5 on 19 October 2026 and says it strongly recommends updating all production installations of 1.6.x and 1.7.x. The release notes list about 20 security fixes. The first to get a CVE record, CVE-2026-113386 (published 20 October, CVSS 3.1 score 7.1), lets a logged-in user inject CRLF sequences into the _uid parameter of the mail/headers and mail/viewsource actions to run arbitrary IMAP commands; a similar IMAP injection through the _flag parameter of mail/mark is also fixed. Other fixes cover mail header injection in the bounce (resend), forward-as-attachment and reply paths, an XSS in password driver error responses, a CSRF check bypass in mark-as-junk, an SSRF filter bypass using NAT64 addresses, remote-content blocking bypasses via SVG and CSS, unsafe attachment content passed to ImageMagick during image resizing, an object injection primitive in session handling, deprecated action aliases that ignored the disabled_actions setting, and a Modoboa password driver bug that could change another account's password. Roundcube has not said any of these are being exploited, but earlier Roundcube flaws have been exploited in the wild, so patch promptly. (source: Roundcube) UPDATE (22 Oct 2026): MITRE published 19 further CVE records for the fixes in 1.6.20 and 1.7.5 on 22 October (CVE-2026-114714 to CVE-2026-114732), with CVSS 3.1 scores from 3.1 to 8.5; the highest is CVE-2026-114716, a mail header injection (8.5), followed by CVE-2026-114727, unsafe content passed to ImageMagick (8.3). (source: CVE records at cve.org, scored by MITRE)
Roundcube — Security updates 1.6.20 and 1.7.5 released (19 Oct 2026)
The Pillow maintainers released Pillow 13.0.0 on 16 October 2026 (UTC) and published 40 GitHub security advisories for it on 17 October: two rated critical, 13 high, 22 medium and three low. The most serious, CVE-2026-112398, is a heap buffer overflow in the FlashPix (FPX) JPEG-tile decoder; the reporter shows code execution from a single crafted file passed to Image.open(), and because Pillow detects FPX by its content rather than its extension, any service that opens or thumbnails untrusted uploads is reachable when the optional olefile package is installed. Other high-severity fixes include JPEG encoder and decoder heap overflows (CVE-2026-96778 when re-saving a JPEG with its colour profile, CVE-2026-112403 via Image.thumbnail()), TIFF out-of-bounds reads that can leak heap memory into pixels, and a heap-buffer-overflow write in the OpenJPEG library bundled in every Pillow wheel since 11.1.0 (CVSS 3.1 8.1), which a patched operating system does not fix. CVE-2026-112900 is a Ghostscript argument injection in EPS handling when a file name starts with a dash. Most of the rest are denial-of-service bugs (decompression-bomb bypasses, infinite loops, quadratic parsing). Some were found by Anthropic using Claude and validated by Ada Logics. Red Hat began listing the CVEs on 19 October. A further moderate advisory published 19 October (GHSA-654x-cwwv-5j9c: Arrow export leaking heap memory when PILLOW_ALIGNMENT is above 1) lists versions from 11.2.1 up to but not including 13.0.0 as affected and 13.0.0 as patched. No exploitation has been reported. (source: Pillow on GitHub) UPDATE (23 Oct 2026): The CVE records published by GitHub, the CVE numbering authority, on 19 October (UTC) score four of the flaws 9.2 under CVSS 4.0: CVE-2026-112398 (FlashPix decoding), CVE-2026-112403 (JPEG decoding after draft()), CVE-2026-112393 (heap buffer overflow when saving TIFF to BytesIO) and CVE-2026-112900 (argument injection in the Ghostscript call, potentially leading to code execution). The maintainers' own advisories rate those four critical, high, high and medium respectively. In the same records, CISA's ADP enrichment records a public proof of concept for CVE-2026-112398, CVE-2026-112403 and CVE-2026-112393, and no known exploitation for CVE-2026-112900. Pillow 13.0.0 remains the fixed release. (source: CVE.org records) Correction (30 Oct 2026): the card said the 19 October Arrow export advisory also affected 13.0.0 and had no fixed release; Pillow's advisory GHSA-654x-cwwv-5j9c lists versions from 11.2.1 up to but not including 13.0.0 as affected and 13.0.0 as patched. (source: Pillow on GitHub)
Pillow GHSA-5x8w-8jj5-q52h — FlashPix (FPX) JPEG decoding heap buffer overflow leads to code execution (CVE-2026-112398, critical; 17 Oct 2026)
Rank Math, maker of the widely used Rank Math SEO plugin for WordPress, published a security incident notice on 16 October 2026 (UTC) saying that some copies of its paid Rank Math PRO plugin, version 3.0.123, contained malware. Only packages downloaded, or installed through an update, between 20:02 UTC on 15 October and 07:12 UTC on 16 October 2026 are affected (about 4:02 am to 3:12 pm on 16 October in Perth). Having version 3.0.123 does not by itself mean a site was compromised. Rank Math removed the affected files and released a clean version, 3.0.124. Wordfence assigned CVE-2026-111862 and rated it CVSS 9.8; Patchstack lists it as a backdoor, published 17 October. If the plugin was activated, the malicious code could set up persistent access and rebuild a hidden backdoor whenever someone visited the site, so deactivating the plugin is not enough. Rank Math warns that WordPress passwords, database credentials, API keys and other secrets the web server can read should be treated as exposed. Indicators from the notice: outbound connections to rank1cdn[.]com; wp_options entries named _uf6qdn2hmm, t8krdk990phb or _np5pvf754c; administrator accounts whose usernames start with wpsupport_ or that use @wp-mail[.]net email addresses; PHP files in the inc/, includes/ or lib/ folders of non-default themes containing base64_decode with XOR loops, the key xmmqhn, proc_open or PHP-FPM socket code; a fake WordPress core file; .htaccess rules that make .cache files run as PHP; and a web-server-user crontab entry tagged #ms6v46. Rank Math has not said how its distribution was tampered with or how many sites received the affected package. The free Rank Math SEO plugin on WordPress.org is not named in the notice. UPDATE (19 Oct, BleepingComputer): BleepingComputer found a PHP malware sample on VirusTotal, named 'cache-preloader-fff033 (1).php', that carries the same indicators as Rank Math's notice, including code that creates administrator accounts with the wpsupport_ prefix and @wp-mail[.]net addresses. It appears to be a first-stage script that drops the wp-includes/class-wp-cache-util.php backdoor named in the advisory, and it can also run commands, change the WordPress database and steal AWS, Cloudflare, Google Cloud and Azure credentials and SSH keys. BleepingComputer could not confirm that this file was delivered through the compromised plugin. Rank Math has not answered questions about how many sites were affected or how the attackers got in.
Rank Math — PRO 3.0.123 security incident: how to secure your website (16 Oct 2026, updated 17 Oct)
Security firm Calif showed a series of iPhone attacks on stage at the Hexacon offensive-security conference in Paris on 16 October 2026. Its newsletter post lists four demos ('Signal 1-click', an iMessage demo, 'Can your iPhone do this?' and 'APT stands for Apple Persistent Threat') and says everything 'will be released in due time'. Stage video posted by jailbreak researcher Billy Ellis, as described by Decrypt, shows an iPhone 18 Pro running iOS 27.0.1 being rebooted, unlocked with its normal passcode, and an SSH session opened as root with about two minutes of uptime, so root access came back on its own after the restart with no computer attached (an untethered jailbreak). heise online reports the chain works on versions up to iOS 27.0.1, Apple's latest public release, and that AI helped find it. Calif has not named the vulnerabilities, released a tool or published a write-up; there are no CVE IDs and Apple has not commented. As of 29 October no source says whether any Apple update fixes the chain: Apple released iOS 27.2 on 26 October, and its security notes credit Calif.io researchers for several flaws but do not mention Hexacon or a jailbreak. No exploitation outside the demo has been reported. (sources: Calif newsletter; heise online) Correction (29 Oct 2026): the card said no fix had shipped, without giving a date; Apple has since released iOS 27.2 (26 October), and neither Apple nor Calif has said whether it fixes the demonstrated chain, so the card now says no fix is confirmed as of 29 October. (source: Apple)
Calif — iPhone: demos revealed at Hexacon Paris (16 Oct 2026)
The maintainers of Pion DTLS, the Go DTLS library used by the pion/webrtc stack and many Go real-time and IoT services, published six GitHub security advisories on 16 October 2026, all credited to Anthropic's OSS Scanner. GHSA-7c2r-jhm9-43vf (critical, CVSS 3.1 9.1) lets an attacker who can redirect a DTLS handshake and has the peer's public certificate impersonate that peer without its private key, because the library chose the verification primitive from the certificate's key type but took the digest from the attacker-controlled signature scheme; the maintainers note that checking the WebRTC SDP certificate fingerprint does not stop it, since the genuine certificate is presented. GHSA-hhpj-h56m-9f2p (critical, 9.1) lets an unauthenticated client skip required client-certificate checks by resuming a DTLS 1.2 session the server cached before the original handshake finished. GHSA-cqhp-ggp7-58qj (high, 7.4) is a similar bypass when an application shares one session store between its outbound connections and its listener. The other three are denial-of-service bugs: an unbounded handshake cache (memory exhaustion), oversized peer RSA keys (CPU exhaustion), and repeated client-certificate verification while the server waits for the client's Finished message. The maintainers say the two session-resumption bypasses do not affect pion/webrtc users, but the impersonation flaw and the DoS bugs can reach WebRTC applications acting as the DTLS server. No CVE IDs were listed at publication and no exploitation is reported. Fixes shipped in v3.1.13 (16 Oct) and v3.1.14 (16 Oct, the session-store fixes); the advisories list no patched v2 release. (sources: Pion DTLS GitHub security advisories; maintainer post on Hacker News)
