Blocking an exploit can also block the transaction a customer needs to complete.
A temporary request filter can interrupt document uploads. Isolating a server can take an application offline. Someone has to decide what can keep running, what needs to stop, and how the business will operate during the repair.
I want that decision made before an incident, with the service owner involved. I also want to know what else an attacker could reach through the system. Its credentials and permissions can turn a problem in one application into a much larger response.
Chris Hughes makes the case for defenses that work while vulnerabilities remain in There’s No Bucket Big Enough, building on Tal Be’ery’s Dense in Depth. Tal argues that software contains a deep reservoir of flaws. Changes in discovery effort make that reservoir hard to measure, but I would not plan on exhausting it. We should use AI to help find and fix vulnerabilities, alongside controls that limit what exploitation can achieve.
Google Threat Intelligence Group reported 5,045 vulnerability disclosures in January 2026 and 10,740 in August. Those figures measure disclosures, not breaches or AI’s contribution to the increase. Google also notes that CVE assignment practices affect the totals. They do not tell us how many urgent fixes apply to any one organization.
| Month | Disclosures |
|---|---|
| January 2026 | 5,045 |
| July 2026 | 10,477 |
| August 2026 | 10,740 |
Prioritize systems that are reachable, have evidence of exploitation, and can cause the greatest business harm. Even a fast patching program needs a way to reduce exposure while a repair is being prepared.
PHP2Shell presents two containment decisions
For a PHP application, a temporary request filter may interrupt customer uploads. In the reported PAN-OS campaign, the immediate exposure was the management interface. The right containment action depends on the service and its attack surface.
AWS’s PHP2Shell guidance describes blocking multipart requests where an application does not require multipart form data. That rule can break legitimate uploads. Having no upload feature does not itself make an application safe: vulnerable PHP request processing can happen before application code runs. AWS describes limits to WAF inspection and makes clear that patching is the complete fix.
If customers need to upload claims or supporting documents, an upload restriction affects the service. An exception may preserve that function while leaving exposure to address. Security needs to explain the residual risk; the service owner needs to explain what will break, whether there is a fallback, and who will be affected.
For PAN-OS, the product advisory recommends removing public internet access to the management interface, restricting management access to trusted internal addresses, and applying the relevant fixes. It says the GlobalProtect portal, gateway and Clientless VPN are not impacted by these PHP2Shell vulnerabilities.
Choose the restriction that addresses the actual exposure. Test it against the relevant attack paths and the legitimate transactions the business still needs. Record the remaining risk and when the temporary measure will be reviewed. If a safe fix can be deployed immediately, apply it without waiting for a separate containment exercise.
If compromise is suspected, begin investigation and evidence preservation alongside containment. A host controlled at root may need rebuilding from a known-good image, as well as patching and credential replacement, before it can be trusted again.
Look at what the compromised system can reach
Dream Research reported attackers chaining PHP2Shell, CVE-2026-109618 and CVE-2026-109619, with the Linux kernel flaw Fragnesia, CVE-2026-46300, to gain root on affected PAN-OS systems. Unit 42 independently verified the attacker’s tooling and confirmed the reported results.
Dream could confirm LDAP credential extraction and directory enumeration. It could not determine whether later password spraying, backdoor-account attempts or SAML signing-key extraction succeeded. Keep that distinction when assessing the reported downstream impact.
A web worker with limited permissions is useful protection. In this campaign, the kernel exploit let the attacker move beyond those limits. Fragnesia requires local access, which remote code execution can provide. Check the vendor guidance for the actual build and verify that the fixed kernel is running.
Once an attacker controls an application, they may be able to use its service account normally. The destination can see a valid credential and allow the request. If that account can read customer records, deploy a release or change another system’s configuration, those permissions become part of the incident.
Map the credentials a service holds and the access it can obtain, including active sessions and the ability to issue replacement credentials. Identify where each credential is accepted and which operations it permits. Network reachability matters, but so does authorization at the destination.
Pay particular attention to accounts shared across services. Narrow permissions while systems are healthy, and find out what will stop if an account is disabled. Giving each workload its own identity can help isolate one without unnecessarily interrupting others.
Railway shows why the response follows the credentials
Railway’s October 22 preliminary report, updated October 26, describes a separate incident involving internal systems, compromised CI credentials and decryption of some stored environment variables. Railway says existing deployments stayed online while builds and deployments were paused. The disruption also affected dashboard, API, CLI and support access.
That is a useful distinction for a response plan: the running workload and the ability to administer or update it have separate dependencies.
Railway worked with GitHub and other providers to revoke potentially compromised keys. Precautionary revocations extended beyond keys known to be affected, so a reset notice does not prove a particular key was stolen. The report describes GitHub’s role in credential response; it does not establish a breach of GitHub’s platform.
Patching the original system does not withdraw credentials an attacker may have copied. Follow each key to the service that accepts it. Check that revoked access is denied, account for active sessions and refresh paths, and keep replacement credentials away from a still-compromised environment.
Leave the rehearsal with a plan responders can use
Choose one important service and rehearse the response with its owner in a suitable test environment. Confirm the restriction works, exercise the fallback, and put a real transaction through recovery. Keep an emergency administration path, monitoring and recovery access that do not depend entirely on the account or host being isolated.
Leave with a short service record: the containment action and approving authority; interrupted transactions and communications owner; fallback and administration access; credentials and sessions to revoke; evidence required to trust recovery; and a review date.
Before restoring access, confirm that the fixed version is running, resolve compromise findings, and test normal application behavior. Systems with significant interruption costs or safety consequences need specific alternatives agreed with the accountable service owner. An exception ticket needs an action and a review date.
Start with one service this week. Agree on what will stop, who can authorize it and how it will recover. Trace the access that could carry the incident into other systems, then rehearse it. That preparation gives responders a decision they can execute when the next urgent patch arrives.
Technical source note
Fragnesia is part of the Dirty Frag vulnerability set. Copy Fail, CVE-2026-31431, is a separate local privilege-escalation issue. Affected products differ; follow the vendor’s guidance for your build. For PHP’s original advisories, see out-of-memory corruption and stale global state.
Image credits: hero illustration adapts the PHP logo by Colin Viebrock under CC BY-SA 4.0; the adapted hero is shared under that license. Linux Tux: Larry Ewing, original artwork created with GIMP. Railway and GitHub marks identify the services discussed.