Daily Cybersecurity News – October 28, 2026

What happened

CISA added two PHP remote code execution flaws known as PHP2Shell to its Known Exploited Vulnerabilities catalog on October 26, 2026, confirming active exploitation in the wild.

CVE-2026-109618 is an out-of-memory corruption issue (CVSS 9.8) and CVE-2026-109619 is a stale internal request-state flaw (CVSS 8.1). Both enable unauthenticated RCE. Researcher Adel Karimi observed successful RCE against honeypots on October 24, including memory disclosure usable in exploits. Patches shipped October 21 in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. A related Brotli decoder issue (CVE-2026-111497) was also added to KEV.

Who is affected

Any internet-facing PHP deployment still running unpatched versions before the October 21 updates. Censys estimates more than 32.51 million PHP services remain on affected builds.

PHP powers roughly 70 percent of websites. Numerous vendors issued advisories, including WordPress, Drupal, Craft CMS, F5, Citrix, IBM, and many appliance and CMS makers that bundle or depend on PHP.

Why it matters

Unauthenticated RCE on the web tier gives attackers immediate code execution with the privileges of the PHP process, often leading to webshells, data theft, or further lateral movement. EPSS scores of 100 percent and confirmed KEV status mean mass exploitation is underway or imminent.

Federal civilian agencies face a short remediation window ending October 29. Operators of high-value or high-exposure PHP applications face elevated risk of compromise if they have not already patched.

How it could have been prevented

Upgrade immediately to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35 (or the corresponding Windows builds that also address the Brotli issue). Restart services after upgrade.

If immediate upgrade is impossible, restrict network access to PHP endpoints, disable unnecessary extensions such as those enabling automatic decompression where relevant, monitor for anomalous process behavior and unusual memory patterns, and prioritize internet-facing and high-privilege instances. Verify patch level across all hosts and containers.

What happened

A critical buffer overflow in EDK II network-boot (PXE) code, tracked as CVE-2026-97631 and rated 9.5 by TianoCore, has existed since a November 2010 commit. It lets an attacker on the local network send a crafted ICMP or status message longer than 504 bytes during PXE boot, overflowing a fixed buffer.

Simple exploitation crashes the boot. With firmware-build-specific tailoring an attacker can plant a counterfeit event that executes arbitrary code inside the firmware before Secure Boot and other defenses activate. The code runs only once per boot but can install persistent implants. No stable EDK II release yet contains the fix.

Who is affected

Systems that perform network (PXE) boots and whose UEFI firmware is built from EDK II up to and including edk2-stable202608 (August 2026). This includes the majority of modern server and workstation firmware from AMI, Insyde, Phoenix, and Microsoft’s Project Mu fork.

Red Hat and SUSE rate it as requiring adjacent-network access rather than remote internet reach. Desktop systems that never PXE-boot are largely unaffected in practice.

Why it matters

Code execution before Secure Boot bypasses the root of trust that protects the boot chain. A successful exploit can install bootkits or firmware-level persistence that survives OS reinstalls and is extremely difficult to detect or remove.

Although exploitation needs precise timing during network boot and build-specific knowledge, the 16-year presence in reference code means millions of devices carry the flaw until vendors ship updated firmware.

How it could have been prevented

Disable PXE/network boot on systems that do not require it. Segment and monitor management networks so untrusted hosts cannot reach PXE clients during boot.

Apply vendor firmware updates as soon as they incorporate the EDK II fix. Until then, treat network-boot environments as higher risk and consider alternative boot methods or additional network controls. Inventory UEFI versions and watch TianoCore and OEM advisories for patched builds.

What happened

An unreleased internal Anthropic research model, given only initial prompting and little human involvement, discovered multiple vulnerabilities across Chrome, Safari, Android, Windows, and Linux, then automatically chained them into working proof-of-concept exploits in a lab setting.

All flaws were reported to vendors first and are now patched. Notable results include a Chrome chain that escapes the sandbox to run code outside the browser from a single page visit (fixed in Chrome 156), a Safari cross-site data read (fixed in iOS/iPadOS 26.5.2), a Windows HTTP/3 denial-of-service (CVE-2026-33096), and a Linux multipath TCP root RCE (CVE-2026-98432). No real-world attacks using these chains have been observed.

Who is affected

Users of the affected products prior to the listed patches: stock Chrome on macOS before version 156, Safari on older iOS/iPadOS, Windows systems answering HTTP/3, Linux hosts with multipath TCP listeners, and certain Android devices. The research itself targeted current mainstream versions at the time of testing.

Why it matters

The demonstration shows that advanced models can now locate distinct bugs and compose multi-step exploit chains that previously required specialized human teams. While these particular chains are patched and remained lab-only, the capability lowers the skill and time barrier for sophisticated attacks once models become more widely available or are misused.

Defenders should expect faster discovery-to-exploit timelines and treat AI-assisted vulnerability research as a new normal that accelerates both offense and responsible disclosure.

What happened

The North Korea-linked Lazarus Group ran Operation FlashHole, a cyber-espionage campaign active since at least July 2025 against South Korean organizations in construction, software, and wire-communication equipment manufacturing.

Attackers sent tailored spear-phishing links to fake portfolio or résumé sites, then abused Initech’s INISAFE CrossWeb EX (mandatory financial/government security software in South Korea) to deliver malware. The campaign continues tactics from the earlier Operation SyncHole that exploited a related Cross EX product. Payloads include backdoors and use post-quantum encryption for command-and-control or data protection. Kaspersky attributes the activity to Lazarus.

Who is affected

At least three confirmed South Korean organizations in the named sectors. Broader risk extends to any entity whose users run vulnerable versions of INISAFE CrossWeb EX or similar mandatory Korean security plugins when visiting compromised or attacker-controlled sites.

Historical Lazarus abuse of the same software family (including 2021-2023 campaigns) indicates recurring targeting of Korean financial and government access tools.

Why it matters

Mandatory security software becomes a high-value single point of failure: once abused it grants reliable initial access on systems that must run it for banking and e-government. Selective spear-phishing plus post-quantum crypto raises the bar for detection and decryption by defenders.

The campaign shows Lazarus continuing to refine South Korea-focused tooling and reuse of local security products for espionage against industrial and tech targets.

How it could have been prevented

Keep INISAFE CrossWeb EX and related Korean security clients fully updated; remove or isolate them on systems that do not require online banking or government portals. Block known malicious domains and use email filtering plus user training against tailored résumé/portfolio lures.

Monitor for unusual process injection into legitimate security binaries, unexpected network connections from those processes, and implement application allow-listing where feasible. Segment networks so compromised endpoints cannot easily reach sensitive internal assets.

What happened

A China-linked threat actor exploited the PHP2Shell pair (CVE-2026-109618 and CVE-2026-109619) chained with a Linux kernel privilege-escalation flaw called Fragnesia (CVE-2026-46300) to gain root on internet-facing firewalls.

Using the FOFA search engine they identified roughly 19,000 candidate firewalls, narrowed to 240 newer-PHP targets in the US, Japan, Taiwan, and South Korea, then automated the full chain against 25 devices on October 23-24. They dropped PHP root webshells on 24. On two servers belonging to a US government-affiliated organization they progressed further: established a reverse SSH tunnel, compromised the internal firewall management server, extracted configurations and credentials, decrypted an LDAP service account, enumerated the domain, and attempted further Active Directory actions.

Who is affected

Internet-facing firewalls from the targeted vendor that run vulnerable PHP and a susceptible Linux kernel. Twenty-four devices received webshells; two in a US government-affiliated environment saw deeper post-exploitation.

Any organization exposing similarly configured appliances remains at risk until both the PHP and kernel issues are patched.

Why it matters

Rooting perimeter firewalls and then the central management server gives attackers visibility into and control over an entire firewall estate plus domain credentials. The speed from public PHP2Shell disclosure to automated mass exploitation and government targeting illustrates how quickly sophisticated actors operationalize new critical flaws.

Persistent webshells and tunnels create long-term access that can outlast simple patching if not thoroughly eradicated.

How it could have been prevented

Patch PHP to 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 or later immediately and apply the kernel update that fixes CVE-2026-46300. Remove or restrict public access to management interfaces and PHP-enabled services on firewalls.

Hunt for unexpected PHP webshells, reverse SSH tunnels, and anomalous authentication from firewall or management hosts. Rotate credentials exposed on compromised devices, review firewall configs for unauthorized changes, and monitor FOFA/Shodan-like exposure of your own appliances.

What happened

The Australian Signals Directorate (ASD) gained access to a criminal Amadey malware controller and disconnected it from approximately 180,000 infected computers worldwide, including systems in Australia.

Amadey, sold as malware-as-a-service since 2018, acts primarily as a loader for further payloads such as the StealC infostealer and can itself steal credentials or provide remote access. Each buyer operates a separate C2 panel. ASD’s action prevents the operator from issuing new commands or receiving fresh data from those bots. The operation is distinct from the broader June 2026 Operation Endgame disruptions that also hit Amadey infrastructure.

Who is affected

Owners of the roughly 180,000 previously infected machines that checked in to this particular controller, plus the criminal operator who lost control. Amadey infections commonly arrive via fake software updates, cracked installers, and other loaders, so home users and organizations with weak endpoint controls are typical victims.

Why it matters

Cutting the C2 link stops ongoing theft and secondary malware deployment from this botnet, reducing immediate harm. However it does not erase credentials or session cookies already stolen; those can be sold or used later to bypass MFA.

The action demonstrates national cyber agencies using offensive capabilities to disrupt commodity malware infrastructure at scale, complementing traditional law-enforcement takedowns.

What happened

Analysis of the recent Shai-Hulud supply-chain attack demonstrates that Software Bills of Materials alone do not give defenders enough real-time insight to detect or respond effectively when a dependency is compromised.

SBOMs list components and versions at build or release time, yet many organizations lack continuous mapping from those components to running production services, containers, and runtime behavior. When a malicious update lands, teams struggle to answer which services are actually affected and whether the bad code is executing.

Who is affected

Any organization that relies on third-party or open-source packages and treats SBOMs as a complete supply-chain security control. Software producers, cloud-native teams, and enterprises with large dependency graphs are especially exposed if they lack runtime visibility.

Why it matters

Supply-chain attacks continue to succeed because static inventories go stale and do not reveal live usage or behavior. Without linking SBOM data to production telemetry, incident response is slow and incomplete, allowing attackers longer dwell time after a package is poisoned.

Builders and operators need to move beyond compliance checklists toward continuous, runtime-aware dependency tracking if they want to contain the next Shai-Hulud-style event quickly.