Attackers took over more than 300 Tor exit relays between 1 and 5 October 2026 and rewrote their exit policies to carry SSH (port 22) and plaintext mail, so that SSH connections made through Tor were redirected to 12 interception servers that could capture passwords. A researcher publishing as kaba noticed a changed host-key warning on 2 October, scanned all of Tor's roughly 3,000 exits that day and found 333 redirecting SSH to the same interception servers; he reported it to the Tor Project's network health team, which also spotted the policy change. Directory authorities flagged affected relays BadExit and MiddleOnly from 18:00 UTC on 4 October, and by 17:00 UTC on 5 October no relay with the attacker's policy remained in the consensus. A directory-data analysis on the tor-relays list counts 377 relays from 59 operators that switched to the attacker's policy between 1 and 4 October (about 7.46% of exit capacity at the peak), many hosted at FranTech/BuyVM. Only password logins could be stolen: a user had to connect to an SSH server over Tor in that window, hit one of the hijacked exits, accept the interceptor's host key and type a password; key-based logins cannot be relayed this way. The interceptor passed the session through to the real server, watched commands and could log in separately with the stolen password to check sudo and run an installer. Relay operator Zimmer (Quetzalcoatl family) wrote in a post-mortem on 7 October that two of his servers had been running the Ebury 1.8.3 OpenSSH backdoor since 28 August, after an attacker logged in with a reused password over SSH password authentication; this Ebury version is newer than ESET's published indicators. No victim count exists and who is behind the campaign is unknown. Primary: Tor Project notice to relay operators (5 Oct) and kaba's write-up (20 Oct); wire: The Hacker News (21 Oct).
kaba — How I got over 300 Tor exit nodes removed (researcher write-up, 20 Oct 2026)
Sophos researcher Gabor Szappanos described a previously undocumented China-aligned threat cluster, Bronze Sandcastle, in a post published on Tuesday 20 October 2026, according to The Hacker News. Between August 2025 and August 2026 the group's attacks hit victims in the Philippines, Taiwan, Afghanistan, Namibia and likely South Korea, and its activity mostly fits the UTC+8 time zone. Its signature technique is DLL sideloading through legitimate Sandboxie executables (SandboxieWUAU.exe loading a malicious sbiedll.dll), plus seven other pairs including NVDA's NvdaHelper.exe, a Java Chromium Embedded Framework helper and Sysinternals bginfo64.exe. The sideloaded DLLs decrypt and run a backdoor kept in an encrypted config.ini file, which collects network and user account details, system information, running processes, keystrokes and screenshots; Sophos has seen versions 1.1.5 and 1.1.7. Version 1.1.5 used dc.cathaypacifice[.]com and net.dpworldto[.]com for command and control, version 1.1.7 pulled encrypted configuration through the GitHub API from a now-removed account, and the payload also talks to file-sharing and messaging services such as file[.]io, gofile[.]io and ably. Sophos says static file detections may miss the encrypted payloads and recommends watching for DLLs that read a local file and immediately execute code in memory. Wire: The Hacker News (21 Oct), citing Sophos.
The Hacker News — China-aligned Bronze Sandcastle abuses Sandboxie DLL sideloading to deploy backdoors (21 Oct 2026)
Google's Chrome Releases blog says Chrome 156 was promoted to the Stable channel on 20 October 2026 (US Pacific time; early on 21 October in Perth) as 156.0.8078.47 for Linux and 156.0.8078.47/.48 for Windows and Mac, rolling out over the coming days and weeks. The update includes 353 security fixes: six Critical, 61 High, 197 Medium and 89 Low. The Critical bugs are CVE-2026-113341 (memory corruption in Skia, found by Google), CVE-2026-113279 (memory corruption in Accessibility), CVE-2026-113072 (memory corruption in CSS) and CVE-2026-113280 (memory corruption in Paint), all three reported by Xinyang Ge; CVE-2026-113271 (use-after-free in Accessibility, reported by Xinyang Ge of Anthropic, assisted by Claude, on 8 October); and CVE-2026-113303 (memory corruption in WebRTC, reported by OpenAI Codex Security on 15 October). High-rated fixes include use-after-free bugs in SiteIsolation (CVE-2026-113101, $10,000 reward), FileSystem, WebUI, Network, Passwords, SVG and V8, and a long run of ANGLE graphics bugs. Google does not say any of the flaws is exploited and does not publish CVSS scores; bug details stay restricted until most users have updated. Chrome 156.0.8078.47 for Android carries the same security fixes, Chrome 156.0.8078.46 shipped for iOS, and ChromeOS Stable moved to 16836.19.0 (browser 156.0.8078.42). This follows Chrome 155.0.8059.84 (15 October), which is a separate card. Primary: Chrome Releases (20 Oct 2026).
Chrome Releases — Stable Channel Update for Desktop, Chrome 156.0.8078.47/.48 (20 Oct 2026)
The FBI, CISA, the US Secret Service, Germany's Landeskriminalamt Rheinland-Pfalz, the UK National Crime Agency and the UK North West Regional Organised Crime Unit published joint advisory AA26-293A on 20 October 2026 on the SafePay ransomware group. They say SafePay has been highly active since August 2024 and was among the most active ransomware groups of 2026, hitting at least 600 victims in multiple critical infrastructure sectors across North America, South America, Europe and Australia. The tactics and indicators come from FBI, Secret Service and German investigations as recently as August 2026. SafePay gets in with exposed or brute-forced credentials and VPN access, often from Mullvad VPN addresses, using phished accounts against Cisco ASA and Firepower Threat Defense flaws CVE-2020-3259 and CVE-2023-20269, and automated scripts that exploit internet-facing systems through Veeam Backup & Replication CVE-2023-27532 and CVE-2024-40711 and SonicWall SonicOS CVE-2024-40766. Once inside, the actors create accounts or take over existing ones, use living-off-the-land tools (PsExec, WinRM, RDP, remote management software and ScreenConnect), enumerate shares with ShareFinder.ps1 and SharpShares, dump credentials with Mimikatz and DCSync tools, bypass User Account Control, turn off security software and sometimes change users' passwords to lock them out. They compress data with 7-Zip or WinRAR and exfiltrate it with WinSCP, RClone, FileZilla, OneDrive or the Backblaze b2 tool, use AnyDesk or TeamViewer to drop the ransomware, stop Volume Shadow Copy and reset backup NAS devices to factory settings, then encrypt files with ChaCha20 and RSA (extension .SafePay). The ransom note points to a Tor chat portal, a representative phones victims to pressure them, and stolen data is posted on the SafePay leak site if they do not pay. The advisory includes IP addresses, file names, hashes and STIX files for indicators seen between November 2024 and August 2026. Primary: CISA AA26-293A (20 Oct); wire: The Record (20 Oct).
CISA, FBI, USSS, LKA Rheinland-Pfalz, NCA and NWROCU — #StopRansomware: SafePay Ransomware (AA26-293A, 20 Oct 2026; PDF and STIX IoCs)
PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 October 2026 to fix CVE-2026-109618 and CVE-2026-109619, two critical flaws each rated 9.2 under CVSS 4.0 that can let an attacker run code on a server without logging in, and PHP says updating is the only complete fix (php.net advisory, 21 Oct). Before the release, the PHP security team had said on 20 October 2026 that it would publish a security release on Wednesday 21 October at 14:00 UTC (10:00 pm Perth, 1:00 am 22 October in Sydney and Melbourne) to fix two critical vulnerabilities, each rated 9.2 under CVSS 4.0, and urged all PHP users to prepare to upgrade as soon as it lands. PHP says it may release earlier if details of either flaw become public or if exploitation appears in the wild, and that affected versions, fixed versions and technical details will only be published with the release. watchTowr told BleepingComputer the two bugs are remote code execution flaws tracked as CVE-2026-109618 and CVE-2026-109619, believed to affect PHP 5, 6, 7 and 8, and that information about them leaked before the originally planned disclosure on Thursday 22 October at 11:00 am US Eastern. watchTowr says it has reproduced CVE-2026-109618 and is holding technical details until patches are out, and that it has not seen exploitation in the wild. A now-deleted Hacker News post had named the same CVE IDs. watchTowr and that post described the flaws as CVSS 10.0, while PHP itself rates them 9.2. PHP runs a large share of web servers, content management systems and e-commerce platforms, including WordPress, Drupal and Magento sites hosted in Australia. Primary: PHP.net news (20 Oct); wire: BleepingComputer (20 Oct). UPDATE (21 Oct): CERT-EU issued Security Advisory 2026-018 on the two flaws (published 20 Oct 20:33, v1.0 dated 21 Oct), saying they could affect all PHP versions from PHP 5 onwards and advising organisations to prepare for immediate patching and, where that is not possible, to consider isolating internet-facing PHP applications from public networks until a fix is applied. As of 08:20 Perth on 21 October PHP had not yet published the release. UPDATE (21 Oct, afternoon Perth): ASD's ACSC issued a 'critical' alert on the two flaws and said it was 'not aware of active exploitation related to these vulnerabilities', according to Information Age (22 Oct). Separately, The Hacker News reports that watchTowr's own FAQ says the PHP 5-onwards scope has not been confirmed by an official vendor advisory and lists no exploitation as of 21 October; Huntress said it had seen no exploitation and knew of no public exploit code as of 20 October; and security firm Mallory counted about 884,000 internet-facing hosts whose banners reported PHP 8.1 or older (end of life, no PHP fix), about 59% of the roughly 1.5 million hosts that reported a version. Researchers have nicknamed the pair 'php2shell'; that is not PHP's name. UPDATE (21 Oct, evening Perth): iTnews reports that, hours after the CVE IDs surfaced on social media, a researcher posted what they claim are full technical details of both flaws and two working exploit samples on the web; iTnews has seen the site but could not confirm the exploits work. PHP had not published the release as of 17:30 Perth on 21 October; its notice says it may release early if details become public. UPDATE (21 Oct, 20:30 Perth): The Hacker News reports that Tokyo firm GMO Flatt Security, which early on 21 October suggested setting session.upload_progress.enabled=0 as a stopgap, said later that day that the setting alone is not a complete fix and that bypasses are expected; PHP core developer Gina Peter Banyard said 'the only mitigation is patching / upgrading PHP', and PHP 8.6 release manager Joe Ferguson said 'ini settings won't save you'. Cloudflare published an emergency WAF release on 21 October adding four 'Anomalous Execution' rules to its Managed Ruleset (two blocking, two logging); THN reports Cloudflare says it is seeing early exploitation attempts and that its CTO calls the rules 'a STOPGAP only'. No compromise had been confirmed, the public exploit code had not been shown to work, and neither CVE was in CISA's KEV catalog as of 21 October. PHP had still not published the release at 20:30 Perth. UPDATE (21 Oct, 23:30 Perth): PHP released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 October (after 10 am US Eastern, 10 pm Perth, according to The Record), saying they fix two critical vulnerabilities that can allow unauthenticated remote code execution and that all PHP users are strongly encouraged to update immediately. PHP says all PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, and that it considers the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs. PHP's GitHub advisories describe CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) as out-of-memory handling that can interrupt PHP while request data is only partially initialised, so that request cleanup treats the invalid data as valid, and CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) as request-owned state that survives after its memory is freed and is used by a later request on the same worker (a use after free); both advisories rate the flaws 9.2 under CVSS 4.0 and list PHP versions below 8.2.35, 8.3.36, 8.4.27 and 8.5.12 as affected. PHP says PHP 8.1 and older no longer receive updates from the PHP project, that it has provided minimal source backports for PHP 7.4, 8.0 and 8.1, and that Linux distributions and LTS vendors received the patches in advance. It says only an update is a complete solution; the interim settings it lists reduce exposure to specific attack paths but do not make an installation safe. BleepingComputer reports the flaws were found by researchers at Calif, Wiz and OpenAI, and that the UK NCSC told UK organisations to update PHP systems immediately or take them offline until they are patched. watchTowr's head of threat intelligence, Jake Knott, told The Record that watchTowr is observing in-the-wild exploitation of the flaws with proof-of-concept tools built with the help of AI, and said: 'Whilst nobody has been successful to date, we don't expect that will last long.' Neither CVE was in CISA's KEV catalog as of 21 October. UPDATE (22 Oct, 2:30 am Perth): The PHP Foundation said in a 21 October blog post that full remote code execution through CVE-2026-109618 was demonstrated on Apache with mod_php with default settings, and that remote code execution was also confirmed on PHP-FPM through application-level code paths. The Foundation says a PHP core developer first found signs of the out-of-memory problem in 2024 while fixing an issue from a Quarkslab audit, that work on a fix stalled and restarted for months, and calls the delay 'a structural failure'; it says a Calif researcher reported an unconditional remote code execution with the same root cause on 11 August, OpenAI independently reported the same root cause that day, and Wiz (24 August) and OpenAI (18 September) reported further attack vectors. The Foundation says the two CVE IDs began circulating online at about 15:00 UTC on 20 October with a wrong release time and a wrong CVSS score of 10.0, so PHP brought its pre-announcement forward and moved the release from 22 to 21 October; it says Calif mistakenly published a video showing its proof of concept working, which contributed to faster development of proof-of-concept exploits, and that the PHP security team did not identify any functional exploits at the time of release. The PHP Foundation also says Chainguard broke the embargo at 07:41 UTC on 21 October, more than six hours before the coordinated release, by publishing built images containing the fix; The Record says Chainguard did not respond to its request for comment. CISA said in a 21 October alert that it strongly urges organisations to patch immediately, that it had not observed exploitation as of publication, and that organisations that cannot update immediately, or that still run PHP 8.1 or earlier, should take PHP-based systems offline until they are patched or updated. Palo Alto Networks said in an advisory published at 16:00 UTC on 21 October (midnight Perth) that PAN-OS and Panorama are affected and that Cloud NGFW, Prisma Access, Cortex XDR Agent, Cortex XSOAR, Cortex Xpanse, Bridgecrew and Idira are not; it says the issue will be fixed in upcoming PAN-OS releases, rates it CVSS-B 8.7 in PAN-OS when the management interface is reachable from the internet (7.1 when access is limited to a jump box), and says it is not aware of malicious exploitation against its products. ConnectWise said on its status page (21 Oct, 17:11 UTC) that it had temporarily taken the x360Recover Manager interface and Backup for Files Portal offline as a precaution in response to a critical PHP vulnerability, and that backups for all Axcient products are not impacted. According to the BBC, Finland temporarily shut down the government's public web services and the Dutch National Cyber Security Centre said it was taking its own website offline because of the flaws. UPDATE (22 Oct, 4:45 am Perth): Linux distributions have shipped fixed packages. Debian's security tracker lists php8.4 8.4.27-1~deb13u1 for Debian 13 trixie (DSA-6574-1) and php8.2 8.2.35-1~deb12u1 for Debian 12 bookworm (DLA-4848-1) as fixed. Ubuntu published USN-8948-1 and USN-8948-2 on 21 October, and its CVE page for CVE-2026-109618 lists fixes in php8.3 8.3.6-0ubuntu0.24.04.13 (24.04 LTS), php8.1 8.1.2-1ubuntu2.28 (22.04 LTS) and php8.5 8.5.4-0ubuntu1.5 (26.04 LTS), with fixes for some older releases available through Ubuntu Pro. The CVE records, published on 21 October, confirm CVSS 4.0 9.2 (AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H) for both flaws, and CISA's enrichment of those records lists exploitation as 'none'. Neither CVE was in CISA's KEV catalog as of its 21 October 14:04 UTC update. PHP has published no new advisory since its 21 October release notice. UPDATE (22 Oct, 5:45 am Perth): Palo Alto Networks updated its advisory at 19:18 UTC on 21 October (3:18 am Perth 22 Oct) to list GlobalProtect App and Prisma Access Agent as not impacted; its FAQ says the issue strictly affects the PAN-OS management web interface (the HTTPS web UI and XML API service), affects a dataplane interface only if a management profile is attached to it, and does not affect GlobalProtect portals and gateways or the captive portal. Palo Alto still lists fixed PAN-OS and Panorama versions as 'ETA: TBD' as of 22 Oct. Red Hat's security bulletin RHSB-2026-013 rates the two flaws Important and lists Red Hat Enterprise Linux 10, 9 and 8 and Red Hat OpenShift Dev Spaces 3 as affected, saying RHEL 7 and earlier ship PHP versions that are not affected; Red Hat says some fixes are already available with more in progress, that standard RHEL deployments use PHP-FPM, where remote code execution is difficult in practice, and that environments running mod_php with default configuration are at higher risk. SUSE's page for CVE-2026-109618 lists fixed php8 8.3.36-150700.3.24.1 packages for SUSE Linux Enterprise Server 15 SP7 and its Web and Scripting module, with the overall issue still marked pending. ConnectWise said at 18:22 UTC on 21 October (2:22 am Perth 22 Oct) that x360Recover Manager and related services had been patched and restored, and that the Backup for Files Portal (Legacy Portal) remained temporarily unavailable as a security precaution. UPDATE (22 Oct, 8:30 am Perth): Palo Alto Networks' advisory timeline now also lists Cortex XSIAM and Prisma Cloud as not impacted and records that Threat IDs were released; it says customers with a Threat Prevention subscription get coverage by enabling Threat IDs 543004, 97622, 97623, 97624 and 97625 (Applications and Threats content version 9162 and later), and that for these Threat IDs to protect against the attack, management traffic must be routed through a dataplane port, the certificate for inbound management traffic replaced, that traffic decrypted and threat prevention enabled on it. Palo Alto still lists fixed PAN-OS and Panorama versions as 'ETA: TBD' as of 22 Oct. Fortinet's PSIRT advisory FG-IR-26-186 (21 Oct) says Fortinet is investigating the impact on FortiADC, FortiADC Manager, FortiClient EMS, FortiDDoS, FortiDDoS-F, FortiSIEM, FortiMonitor, FortiClient Cloud, FortiSOAR, FortiSOAR PaaS, FortiGuard and FortiEndpoint, lists FortiOS, FortiManager, FortiAnalyzer, FortiWeb, FortiMail, FortiClient for Linux, Windows and macOS, FortiSASE, FortiAuthenticator, FortiSwitch and FortiNAC as confirmed not impacted, and marks the issue 'Known Exploited: No'. The WA Government's Cyber Security Unit (WASOC) published advisory 20261022001 on 22 October recommending that administrators apply PHP's fixes, and said it had not received any reports of exploitation on Western Australian Government networks at the time of writing. UPDATE (22 Oct, 11:00 am Perth): Amazon Threat Intelligence says in an AWS Security Blog post (21 Oct, 22:36 UTC; 6:36 am Perth 22 Oct) that it identified a PHP2Shell exploitation attempt dating to 17 October in its MadPot honeypot telemetry, four days before public disclosure, from an IP address associated with a commercial anonymization network, and that it remains unclear how the actor acquired exploit information before disclosure. Amazon says it identified multiple proof-of-concept exploits on release day, the earliest around 02:00 UTC on 21 October, and further exploitation attempts against MadPot from other anonymized infrastructure between 02:00 and 08:00 UTC that suggested multiple actors; it says it is unclear if any of these attempts would have succeeded in real-world systems. Amazon says that once the embargo lifted at 14:00 UTC additional proof-of-concept exploits appeared within hours and were used against its sensors almost immediately, that PHP2Shell is now being broadly exploited in the wild, and that investigations should start from at least 17 October. AWS Security Bulletin 2026-143-AWS (first published 21 Oct) says AWS services are not impacted and that PHP 5.4 to 8.1 have no upstream fix; see the 23 Oct update for the status of AWS's own fixes. In Australia, according to Information Age (ACS), ASD said on Wednesday night (21 Oct) that it was 'aware of an outage that may be affecting government websites', including its own. ASD's 'ALERT UPDATE' post on X (22:51 UTC on 21 Oct; 6:51 am Perth 22 Oct), embedded in the Information Age report, says 'Patches are now available for two critical PHP vulnerabilities' and recommends that organisations using PHP identify affected systems, review official PHP guidance and apply appropriate mitigations as soon as possible. According to ABC News (22 Oct), GovCMS, which hosts many major Australian government websites, blocked direct access to its servers while keeping cached copies of public pages available; Moodle 'took its website offline as a precaution, before beginning to restore them after applying security fixes'; and Australian hosting provider VentraIP restricted some of its file uploads on customer hosting. UPDATE (23 Oct 2026, 7:45 am Perth): AWS updated Security Bulletin 2026-143-AWS at 14:00 PDT on 22 October (5:00 am Perth 23 Oct) to say its fixes have shipped: for Amazon WorkMail 'AWS has applied configuration-level controls and has completed the upgrade to PHP 8.3.36. No customer action is required'; for Elastic Beanstalk it 'has released updated PHP platform versions for all supported PHP versions (8.2 through 8.5) containing the upstream PHP fix'; updated Amazon Linux PHP packages are available for commercial regions, with non-commercial regions targeted for 22 October; and 'Updated Lightsail blueprints are now available in all regions'. AWS still says AWS services are not impacted and that PHP 5.4 to 8.1 have no upstream fix. Fortinet updated FG-IR-26-186 on 22 October: only FortiDDoS, FortiDDoS-F, FortiClient Cloud Services, FortiSOAR and FortiSOAR PaaS remain under investigation; FortiADC, FortiADC Manager, FortiClient EMS, FortiSIEM and FortiMonitor, among others, are now listed as confirmed not impacted; and it still marks the issue 'Known Exploited: No'. UPDATE (23 Oct 2026, 11:40 am Perth): Palo Alto Networks updated its advisory on 23 October to list WildFire Appliance WF-500 and WF-500-B as affected, with no fixed version yet ('ETA: TBD'); it says Cortex XCORE (SaaS) and WildFire Cloud were previously impacted and received remediation patches on 21 and 22 October respectively, and lists Cortex XDR Broker VM and Strata Cloud Manager as not impacted. At that update, fixed PAN-OS and Panorama versions were still 'ETA: TBD'. UPDATE (23 Oct 2026): Palo Alto Networks updated its advisory again at 03:45 UTC on 23 October (11:45 am Perth) to list fixed PAN-OS hotfix versions with estimated release dates from 26 to 30 October, for example 12.2.4-h1 (ETA 28 Oct), 12.1.10-h3 (ETA 30 Oct), 11.2.10-h16, 11.1.16-h4 and 10.2.18-h13 (ETA 26 Oct); Panorama and WildFire WF-500/WF-500-B still show no fixed version ('ETA: TBD'). Palo Alto still rates its own exposure CVSS-B 8.7 (High). (source: Palo Alto Networks advisory CVE-2026-109618) UPDATE (23 Oct 2026, 2:40 pm Perth): According to the BBC's live coverage on 22 October (UK time), a UK minister said 32 UK government services were unavailable and four partially unavailable because they were being fixed, and technology minister Baroness Lloyd of Effra said: "Whilst we have heard reports of exploitation activity and scanning internationally, we are not aware of any compromises in the UK public sector or in the UK as such." The UK NCSC's chief technology officer Ollie Whitehouse told BBC Radio 4 that the "scale of this is unprecedented" and that there are "no indications" at the moment of "any successful breaches", according to the BBC. The BBC also reports that the Government of Canada said some of its websites may be unavailable or disrupted while security updates are applied, and that "there is no indication at this time that any Government of Canada systems or information holdings have been compromised". UPDATE (23 Oct 2026, 5:40 pm Perth): Sophos corrected its own earlier report. In an update at 21:21 UTC on 22 October it said its customer telemetry shows scanning and a small number of failed exploitation attempts, not the successful exploitation it had reported at 16:18 UTC, and that there is no evidence of a successful compromise due to these vulnerabilities as of that update. Sophos says the attempted payload, a likely Mirai botnet variant known as Potassium, was not delivered because Sophos countermeasures blocked it, and that developing a successful exploit is not straightforward, but it still recommends urgent patching. (source: Sophos) UPDATE (25 Oct 2026): Palo Alto Networks revised its advisory again on 25 October, removing the estimated release dates for PAN-OS 10.2.18-h13, 11.1.16-h4 and 11.2.10-h16, which the advisory now lists as fixed versions without an ETA; the other PAN-OS hotfixes still carry ETAs from 27 to 30 October (for example 11.2.13-h4 and 11.1.13-h16 on 27 October, 12.2.4-h1 on 28 October and 12.1.10-h3 on 30 October). The advisory's product table now lists WildFire Appliance WF-500 and WF-500-B as unaffected, following a 23 October revision that Palo Alto describes as a correction to their impact status, and it has no separate Panorama row; its note says the issue applies to PAN-OS on PA-Series and VM-Series firewalls and on Panorama (virtual and M-Series). On 24 October Palo Alto added 20 more Threat Prevention signatures (Threat IDs 97643 to 97678, as listed in the advisory; content versions 9162, 9163, 9164 and later). Palo Alto still says it is not aware of any malicious exploitation of this issue against its products. (source: Palo Alto Networks advisory CVE-2026-109618) UPDATE (25 Oct 2026, 11:30 pm Perth): Palo Alto Networks reworded its 25 October timeline entry (05:25 UTC, 1:25 pm Perth) to say it removed the ETAs for PAN-OS 10.2.18-h13, 11.1.16-h4 and 11.2.10-h16 'as these versions are released'; the other PAN-OS hotfixes still carry ETAs from 27 to 30 October. (source: Palo Alto Networks advisory CVE-2026-109618) UPDATE (26 Oct 2026, 2:30 am Perth): Palo Alto Networks Unit 42 updated its PHP2Shell threat brief on 23 October (12:30 pm PT) to add agentic AI post-exploitation activity. Unit 42 says it observed attackers using agentic AI attack platforms after exploitation, and that in one case attackers targeted a government entity in Europe and, within two hours of the initial exploitation, had accessed password hashes and multi-factor authentication secrets, set up an NTLM-relay tunnel into Active Directory and attempted Domain Admin privilege escalation. (source: Palo Alto Networks Unit 42)
PHP.net — Security advisory: Critical remote code execution vulnerabilities, update now (PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35; 21 Oct 2026)
Oracle released its quarterly Critical Patch Update for October 2026 on 20 October (US time; early 21 October in Australia). The advisory (Rev 1) contains 1,295 new security patches, slightly more than the 1,283 in the 15 October pre-release notice. The largest groups are Oracle Fusion Middleware (206 patches, 134 remotely exploitable without authentication), E-Business Suite (194; 31), Database products (126 in total, including 14 for Oracle Database Server, 38 for Essbase and 35 for REST Data Services), Siebel CRM (122; 66), Communications (110; 77), PeopleSoft (109; 41), JD Edwards (102; 44), MySQL (98; 29) and Java SE (55; 49). Six flaws carry the maximum CVSS 3.1 score of 10.0, all reachable over the network without credentials: CVE-2026-101809 in the E-Business Suite Workflow Notification Mailer (12.2.3 to 12.2.15, HTTP); CVE-2026-87337 in the Oracle Access Manager authentication engine (12.2.1.4.0 and 14.1.2.1.0, HTTP); CVE-2026-91231 (Adapters, HTTP), CVE-2026-91216 and CVE-2026-91221 (Fabric Layer, T3/IIOP) in Oracle SOA Suite 12.2.1.4.0 and 14.1.2.0.0; and CVE-2026-91299 in JD Edwards EnterpriseOne Orchestrator security (9.2.0.0 to 9.2.26.5). Unauthenticated 9.8 fixes include Oracle WebLogic Server core CVE-2026-91323 (HTTP) and CVE-2026-83399 (T3/IIOP) for 12.2.1.4.0, 14.1.1.0.0, 14.1.2.0.0 and 15.1.1.0.0; a second Access Manager flaw over SAML (CVE-2026-87251); the E-Business Suite Application Object Library (CVE-2026-101767); Oracle Identity Manager (CVE-2026-91408); Oracle APEX (CVE-2026-101521); several SOA Suite, Data Integrator, WebCenter and Managed File Transfer issues; an OpenSSL component flaw in Oracle Database Server (CVE-2026-75803, 19.3 to 19.32 and 23.4.0 to 23.26.3); OpenSSL and curl component fixes in MySQL Server and MySQL Enterprise Backup; PeopleSoft PeopleTools (CVE-2026-33466, Logstash component); and Oracle Solaris (CVE-2026-60432 in the Image Packaging System and CVE-2026-101537). Java SE fixes top out at 7.5 and cover Java SE 8u503, 11.0.32.1, 17.0.20.1, 21.0.12.1, 25.0.4.1 and 27 plus GraalVM. Oracle does not say any of these flaws are being exploited, but repeats its warning that attackers keep succeeding against customers who have not applied earlier patches. PeopleSoft was hit by a renewed mass-exploitation campaign in September (CVE-2026-35273). Oracle's next releases are monthly Critical Security Patch Updates on 17 November and 15 December 2026, with the next quarterly CPU on 19 January 2027. Primary: Oracle CPU advisory (20 Oct). Oracle is on this desk's vendor watchlist.
Oracle — Critical Patch Update Advisory, October 2026 (Rev 1, 20 Oct 2026)
Siemens Software Center Uncontrolled Search Path Element Vulnerability. Siemens Software Center contains an uncontrolled search path element vulnerability that could allow an authenticated local attacker to place a specially crafted DLL in a directory that the application searches, leading to arbitrary code execution with the privileges of the affected application. Apply vendor mitigations. Check the NVD record and the vendor advisory for affected versions and the patch.
EG Secure Solutions SiteGuard Server Edition OS Command Injection Vulnerability. EG Secure Solutions SiteGuard Server Edition contains an OS command injection vulnerability which may allow an attacker to execute arbitrary OS commands with root or SYSTEM privileges on the system running the affected product. Apply vendor mitigations. Check the NVD record and the vendor advisory for affected versions and the patch.
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. The Hacker News reports a commenter matched the hashes to EM DV, OV and EV TLS CA - G3B/G3C and EM OV CS CA - G3B/G3C under emSign Root TLS CA - G3 and emSign Root CS CA - G3. Microsoft and Apple had not published a response. Primary: Mozilla dev-security-policy (Mozilla and Chrome Root Program posts); vendor: Go issue 82345; wire: The Hacker News (20 Oct). 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 this desk'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.report) UPDATE (25 Oct 2026; Oracle): Oracle has issued two Java Security Alerts for the eMudhra certificates. It says CVE-2026-91403 (21 October) provides Java updates that distrust the impacted eMudhra intermediate CA certificates, and CVE-2026-114820 (24 October) provides Java updates that remove the impacted eMudhra root CA certificates; Oracle scores both CVSS 3.1 9.1 for Oracle Java SE and GraalVM and tells customers to update to the latest Java version or apply the recommended mitigations. (source: Oracle Security Alert Advisory - CVE-2026-91403; Oracle Security Alert Advisory - CVE-2026-114820)
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 unreleased 12 development branch 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; the advisory GHSA-753w-2942-4pxm and a CVE are not yet published. 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. Primary: Mobeta.
Mobeta — Unauthenticated SQL injection in GLPI (≤ 11.0.8) (20 Oct 2026)
PingCAP published a security incident report on 19 October 2026 saying that between 9 September and 7 October 2026 an unauthorised party used stolen service-account credentials to access certain PingCAP internal systems, copy data and obtain source code. PingCAP says it became aware on 7 October and began disabling the affected credentials that day, deleted further compromised credentials and removed excessive cross-project permissions by 10 October, and that as of 14 October all identified compromised credentials were invalidated and identified unauthorised access paths blocked. PingCAP says exported records included TiDB Cloud user names and email addresses, organisation and project associations, SQL editor text and errors, and some organisation, project and cluster identifiers, plus business and billing information (customer contacts, contract terms, orders, pricing, payment terms and billing configuration); it says this does not mean every customer had every category exposed and it is still establishing per-customer impact. It says an exported table contained encrypted TiDB Cloud API-key values and that one investigator-owned value tested by its external incident response firm could not be used directly as an API key, while whether other usable credentials were exposed is still being determined. PingCAP says the external firm found no evidence the attacker ran commands or kept persistent access in the production systems reviewed, and that with outside counsel and forensic specialists there is no evidence data stored in TiDB was impacted. It says the firm reported four vulnerabilities on 12 to 13 October, which PingCAP fixed by 14 October, and that it is checking production logs for earlier exploitation. PingCAP says it will notify affected customers directly. Source: PingCAP security incident report (19 Oct 2026). UPDATE (24 Oct 2026): PingCAP co-founder and CEO Max Liu published a note on 23 October apologising to customers, saying 'This happened on my watch' and that he takes responsibility for it, and pointing to a completed independent investigation by NebuSec. NebuSec's report (findings as of 21 October) says the attacker got in through a compromised GitHub account exposing private repositories, then used keys and tokens harvested from those repositories and Terraform state to reach Google Cloud, Jira and the internal chat system used for TiDB alerts. Through Jira support tickets it harvested credentials customers had shared during support work, including AWS keys that reached several S3 buckets holding customers' TiDB diagnostic data. NebuSec says eight compromised Google Cloud service accounts were used, 6,458 BigQuery tables were exported on 23 and 24 September and Cloud Storage data was downloaded with rclone; the data taken includes TiDB Cloud control-plane metadata, customer SQL editor history, AI interactions and gateway connection logs, CRM and billing records, support tickets and attachments with embedded credentials, source code, Jira issues and internal chat history. NebuSec found no evidence that data in customer TiDB databases was accessed or of attacker command execution or persistence in production, and says the encrypted TiDB Cloud API-key values could not be decrypted because the encryption key was not exposed, which does not apply to credentials shared in support materials. It says the four vulnerabilities it found were patched and retested with no evidence of earlier exploitation, and it publishes six attacker IP addresses. (source: PingCAP CEO note; NebuSec)
PingCAP — Security Incident Report: Unauthorized Access to PingCAP Cloud Resources (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). Updated 22 Oct 2026: The Hacker News reported the fix. (source: The Hacker News)
Laravel — GHSA-f9x3-7vq9-cph6: Token-based API guard Auth Bypass (19 Oct 2026)
