Two Critical PHP Flaws Get Emergency Patches Today

PHP’s security team is pushing out fixes for two critical remote code execution flaws, reportedly after details leaked ahead of coordinated disclosure. This post covers what has been confirmed so far and how to prepare before the updates ship.

What You Need to Know

PHP has scheduled the updates for October 21, 2026, at 14:00 UTC (10:00 a.m. Eastern) for two remote code execution vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Each is rated CVSS v4.0 9.2. Information about the flaws reportedly leaked before coordinated disclosure, which shortened the patching window for administrators. Between now and release, the work is preparation: know where PHP runs, who owns each update, and how you will deploy fixes once they ship.

What’s Been Disclosed

Researchers at watchTowr identified both flaws and described them as remote code execution vulnerabilities. PHP’s advance notice did not include affected versions, fixed releases, or the technical requirements for exploitation. The security team said it may release earlier than planned if vulnerability details become public or it sees evidence of active exploitation.

watchTowr said it believes it has reproduced CVE-2026-109618 and reported that exposure may span several PHP generations. PHP has not confirmed that scope. The two also disagree on severity: watchTowr scored both flaws at CVSS 10.0, while PHP’s official assessment puts each at 9.2.

Why This Matters

There’s a gap between what PHP has confirmed and what the researchers have reported. That doesn’t make the flaws less urgent, but it does mean early version claims and scores shouldn’t be treated as final. watchTowr reported no exploitation in the wild, and the reported leak doesn’t show a working exploit. Several details that decide who is at risk are still unknown: which configurations are vulnerable, whether authentication is required, and whether either flaw depends on a specific extension or request-handling path. Until the advisory answers those questions, assume any PHP deployment could be in scope.

What to Do

Use the time before release to find PHP across internet-facing applications, internal services, container images, and vendor-managed platforms. Start with externally reachable systems, and keep the full inventory ready to check against the official advisory. For each deployment, confirm whether updates come through operating system packages, upstream builds, container rebuilds, or an application vendor, and assign an owner to each path. Prepare compatibility checks, rollback procedures, and service-restart plans now so change coordination doesn’t hold things up once fixes land.

Where practical, restrict unnecessary external access while exploitation conditions are unconfirmed. A generic firewall rule or application-layer filter may not cover a vulnerability nobody has described yet, so don’t count on one. After release, check the affected-version matrix, install the right updates, and confirm that running services and deployed images actually contain the corrected PHP build. Base remediation decisions on PHP’s technical guidance rather than on assumptions drawn from the leak.

Chrome Now Warns Before ClickFix Commands Leave the Browser

Google is adding a Chrome safeguard against ClickFix, a social engineering technique that gets users to run malware themselves. Below is how the warning works and what organizations should weigh before turning it on.

What You Need to Know

Chrome can now detect when a user has been tricked into copying a suspicious command and warn them before they run it. The feature is available to users with Enhanced Protection turned on. It targets a technique that gets around download protections entirely by having victims execute malware through operating system tools. Security teams get a useful new checkpoint, though it doesn’t replace endpoint controls or user training.

What’s New

When Chrome detects that a user has copied a suspicious command, it strips any personal information the clipboard contents might contain and sends the payload to Safe Browsing for analysis. If Chrome classifies the command as dangerous, it shows a warning meant to stop the user before they run it. Attackers can avoid download protections by persuading victims to fetch and run malware with operating system tools, so no malicious file ever passes through the browser. Chrome now evaluates the instructions that would start the infection instead of waiting for a file.

How ClickFix Works

ClickFix dresses up an unsafe action as routine troubleshooting. Victims land on compromised websites or malicious ads that redirect them to pages showing fake Cloudflare checks, Google reCAPTCHA prompts, or made-up technical errors. The page then tells the user to paste a command into the Windows Run dialog or macOS Terminal, supposedly to finish verification or fix the problem. Running that command can kick off a multistage infection that installs information stealers or remote access trojans. On Windows, attackers often use legitimate utilities like PowerShell and cmd.exe to download more payloads, which hides the malicious execution inside normal administrative activity.

Why This Matters

A ClickFix attack turns on the moment the user goes from reading instructions on a website to carrying them out on their own machine. Chrome’s warning lands right before that step, while the user is still in the browser and before the deceptive page turns into local code execution. The protection has limits. It only covers users with Enhanced Protection enabled, which isn’t every Chrome installation. A browser warning also isn’t guaranteed to catch every malicious command, and it can’t stop a user from running one some other way.

What to Do

Check whether Enhanced Protection is enabled across your managed browsers and whether it suits your environment, keeping in mind that it sends suspicious clipboard content out for security analysis. Treat it as one layer alongside endpoint controls and user education. Keep visibility into command execution and any outbound connections that follow. During investigations, reported verification prompts and copied commands can add useful context alongside endpoint telemetry.

Awareness training should cover fake verification and repair prompts directly, with one clear rule: never paste commands from a website into Run, PowerShell, Command Prompt, or Terminal.

Bronze Sandcastle Hides Backdoors Behind Trusted Sandboxie Executables

A China-aligned threat cluster is loading its backdoors through signed Sandboxie binaries. Below we break down the loading chain and the backdoor’s capabilities, then cover how to hunt for it without relying on filenames.

What You Need to Know

Bronze Sandcastle, a previously undocumented China-aligned cluster, is sideloading malicious DLLs through legitimate Sandboxie executables to plant backdoors in organizations across Asia and Africa. The activity ran from August 2025 to August 2026, and the backdoor supports reconnaissance, keylogging, and screenshot capture. Because the loader sits behind a trusted, signed executable, defenders should hunt for the execution sequence rather than a single file or indicator.

How the Attack Works

Sophos documented the activity, which hit victims in the Philippines, Taiwan, Afghanistan, Namibia, and likely South Korea. The group’s signature technique places a malicious sbiedll.dll next to the legitimate SandboxieWUAU.exe executable, so the trusted application loads attacker-controlled code. Sophos also found seven other sideloading combinations, so searches shouldn’t stop at one executable name.

The chain keeps the loader separate from the payload. The malicious DLL reads an encrypted config.ini file and executes its contents, which lets operators swap the payload without replacing the loader. Renamed legitimate executables help the activity blend in, and runtime decoding with in-memory shellcode execution cuts down on additional files written to disk.

The Backdoor

Researchers found backdoor versions 1.1.5 and 1.1.7. Both can enumerate local networks and user accounts, collect system information and running processes, record keystrokes, and capture screenshots. Observed communications included file-sharing and messaging services, possibly for additional tasking. Version 1.1.7 also used the GitHub API to pull encrypted configuration files from repositories tied to an account that’s no longer accessible.

Why This Matters

This campaign takes advantage of the trust defenders give signed, legitimate software. The problem is that a trusted executable will load whatever DLL sits next to it. That’s abuse of the application’s DLL-loading behavior, and it doesn’t indicate that Sandboxie’s distribution infrastructure was compromised. Attribution needs the same care. The China alignment applies to Bronze Sandcastle as a tracked cluster, and other groups using Sandboxie in similar ways aren’t necessarily the same actor. Network activity calls for the same caution: a connection to GitHub or a file-sharing platform doesn’t, on its own, mean a host is compromised.

What to Do

Focus on the link between a trusted executable, the DLL it loads, and what happens next. Hunt for unexpected copies of SandboxieWUAU.exe paired with sbiedll.dll and config.ini, especially outside approved installation locations, and allow for renamed executables when reviewing results. A valid digital signature on the executable tells you nothing about the accompanying DLL or the code it runs.

Sophos recommends behavioral detection for DLLs that read local files right before in-memory execution, which matches the pattern of decoding and staging an encrypted payload. Correlate those events with unusual outbound connections, account and network enumeration, or signs of screenshot and keystroke collection. When investigating, keep the executable, DLL, and encrypted configuration together, since the loader alone may not show everything the backdoor does. Detection built around this execution sequence will hold up better than filenames, static signatures, or individual network indicators.

Ransomware Groups Are Turning a GlobalProtect Bypass Into Full Network Access

Attackers are exploiting a Palo Alto Networks GlobalProtect authentication bypass that was patched in May. We trace how they get from a VPN session to ransomware deployment, and why organizations that already patched may still have work to do.

What You Need to Know

Qilin, Inc, and other ransomware groups are exploiting CVE-2026-0257, a GlobalProtect authentication bypass, to break into organizations in healthcare, education, government, and energy. The flaw lets remote, unauthenticated attackers set up VPN sessions, get around MFA, and work toward virtualization, domain, and backup infrastructure. Any organization exposed after the May disclosure should treat this as both a patching job and a possible compromise investigation.

What’s Vulnerable

CVE-2026-0257 stems from insufficient validation and integrity checks of authentication cookies, which lets remote, unauthenticated attackers open unauthorized VPN connections. Affected deployments include GlobalProtect portals and gateways on physical and virtual firewalls running PAN-OS, as well as Prisma Access.

Palo Alto Networks rated the flaw medium severity when it disclosed it on May 13, then acknowledged limited exploitation attempts on May 29. Rapid7 saw attackers targeting local administrator accounts starting May 17, and some reached internal networks during a second wave on May 21. Unit 42 has been investigating related intrusions since early June and named Qilin and Inc among the ransomware operators exploiting the flaw.

The Attack Chain

Unauthorized VPN access is only the first step. Attackers can bypass MFA to open sessions that look like normal remote work, then use legitimate IT management tools for discovery and lateral movement before stealing credentials, exfiltrating data, and deploying ransomware.

In one Unit 42 investigation, attackers moved from the compromised VPN gateway to a vCenter management appliance and disabled security controls on ESXi hypervisors. They used a custom tool to pull credentials offline from a domain controller’s virtual disk. Because the theft happened against the virtual disk instead of the running Windows environment, it got around security controls and EDR inside the guest system. Unit 42 also saw attackers pair this access with tools targeting Veeam backup infrastructure through CVE-2023-27532. Separately, ReliaQuest tied exploitation to Qilin and Settra activity and found Cobalt Strike, BloodHound, and SharpHound in related intrusions.

Why This Matters

The initial medium-severity rating undersold this flaw. A cookie validation bug in a VPN gateway turned into a path to hypervisors, domain controllers, and backups, which are the systems ransomware operators need to do the most damage and block recovery. Exploitation began within days of disclosure, so an organization that patched in June or later may have been compromised before the fix went in. The patch closes the entry point, but it won’t remove access attackers already set up or undo the theft of credentials they already took.

What to Do

Upgrade affected deployments, disable authentication override cookies where you don’t need them, and terminate active GlobalProtect sessions after patching. Review unexpected VPN connections and unusual client hostnames, including reported examples like “kali,” though a hostname alone isn’t proof of malicious activity. Correlate suspicious sessions with later access to virtualization management, domain controllers, backup systems, and administrative tooling. Given how this attack chain works, the review should extend past the firewall to those systems.

If your environment stayed exposed after the May disclosure, scope the investigation to the documented exploitation timeline rather than only recent sessions.

eMudhra Certificate Keys Were Weak Enough to Guess

Researchers compromised eight eMudhra intermediate CA certificates after finding that their private keys could be recovered from public data. We cover how the keys ended up that weak and where exposure may still remain.

What You Need to Know

All eight compromised private keys were integer values below 256, small enough to recover with a trivial search. Browsers, Apple, and Microsoft have already blocked the certificates, and about 30,000 certificates will need to migrate. The larger concern is software that maintains its own trust store, which won’t automatically receive browser protections.

What Happened

The affected certificates include six TLS intermediates trusted by major browser root programs and two code-signing intermediates trusted by Microsoft, covering eMudhra’s G3B and G3C series. Mozilla investigator Dennis Jackson reported that all eight P-384 private keys were integer values below 256. Researcher Wayne proved possession by signing a message with each compromised key and notified root programs on October 17, 2026. Mozilla independently recovered the keys that evening. The incident was disclosed publicly on October 20 and also affected Sectigo cross-signed certificates containing the same compromised public keys.

Firefox and Chrome blocked the compromised intermediates on October 17, Apple on October 19, and Microsoft on October 20. eMudhra revoked its eight certificates on October 18, and Sectigo then revoked the affected cross-signs. Mozilla also requested emergency distrust of the emSign ECC Root CA – G3. eMudhra stopped issuing under that root and estimates that around 30,000 certificates will need to migrate, 97% of them issued through ACME.

How the Keys Got Weak

eMudhra’s preliminary investigation traces the failure to a key-generation ceremony on April 30, 2025. Strong keys were first generated inside hardware security modules, but a modified script that added a wrap/unwrap test produced weak alternatives. Because the key labels looked similar, staff picked the wrong keys when creating certificate signing requests. That mismatch also explains earlier invalid Certificate Revocation List signatures: lists signed with the original keys couldn’t be verified against certificates holding the weaker public keys. Those lists were later signed with the compromised keys.

Why This Matters

This was a process failure in key generation and selection, and it reduced strong P-384 cryptography to values anyone could recover. Holding an intermediate CA’s private key undermines trust in every certificate it signs, and two of these intermediates were trusted for code signing. The disclosure found no Certificate Transparency entries showing exploitation against browsers that enforce CT requirements, but the risk to non-browser clients is still unknown. Browser protection doesn’t automatically extend to command-line tools or software that ships its own CA bundle, and clients without working revocation checking may stay exposed until their trust data is updated.

What to Do

Update browsers, operating systems, development runtimes, and certificate bundles, then check applications that maintain their own trust stores. If you hold certificates, identify any affected chains and coordinate replacement with your provider. Security teams should separately confirm that updated distrust information has actually reached non-browser clients instead of assuming a revocation or browser update covers them.