AI is speeding up cyberattacks. Can your team patch production fast enough?

By Thunkle · Incident sources checked 22 October 2026

Your repository can be up to date while production is still vulnerable. The old container is running, the worker never restarted, or the deployment only replaced half the instances.

That is why “we updated the dependency” is not a sufficient answer to a critical security advisory. The update needs to reach the component accepting real requests, and someone needs evidence that it did.

The recent PHP2Shell disclosures are a useful test of that distinction. They also challenge a reassuring assumption about AI-built apps: that reviewing the application code is enough. A runtime vulnerability can sit below code that otherwise behaves correctly.

If you need help connecting code review to your live application's permissions and deployment configuration, start with Thunkle's security audit service. Agree the runtime and infrastructure scope explicitly. Repair and deployment implementation can be scoped separately.

What the PHP releases actually addressed

On 21 October, PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix CVE-2026-109618 and CVE-2026-109619. Its official advisory warns of unauthenticated remote code execution and urges updates for installations serving web requests.

Those are the upstream releases announced that day, not an evergreen instruction to pin to those exact versions. Check the current advisory and your distribution or hosting provider's fixed package. Vendors may backport fixes without adopting the corresponding upstream version number. An older-looking number alone cannot settle whether a vendor package contains the patch.

The PHP Foundation's account explains the underlying memory-management and error-handling problems, the difficulty of fixing them and the coordinated release. This was runtime remediation, not a missing validation check in one particular website.

Wiz's PHP2Shell research describes AI-assisted work developing and adapting exploits against representative applications. That does not mean 70% of websites were hacked. A technology's prevalence, a vulnerable deployment, an exploit attempt and a confirmed compromise are different claims.

Faster attacks leave less room for an improvised response

There is evidence of acceleration beyond laboratory demonstrations. In its 21 October report, Microsoft described Storm-0940 using ARTEX and observed multiple instances of privileged cloud access within three hours of initial targeting. That is not a universal attack timeline. Microsoft also distinguished successful authentication from confirmed data access or exfiltration.

The ARTEX campaign is separate from PHP2Shell. ConnectWise's advisories explicitly separated its Cloud Backup incident from PHP-related remediation for other services. Microsoft stated that the ARTEX activity did not result from a vulnerability in Microsoft's products or services.

The operational conclusion is narrower and more useful than a dramatic countdown: if finding the owner of production takes a day, an emergency patch process has already lost time before anyone starts the build.

AI can help defenders too. OpenAI's coordinated-disclosure account emphasizes the work between an upstream fix and protection across distributors, providers and deployed systems. Your application is at the end of that chain. Someone still has to finish the update there.

Inventory the runtime, not just the repository

A lockfile records part of an application's dependencies. It is not a complete inventory of the infrastructure serving it.

For a PHP incident, inventory the relevant web runtimes and execution modes, including provider-managed installations. Record scheduled jobs and long-lived CLI workers separately so you know what shares the package and what needs restarting. Do not assume every CLI task has the same remote attack path as a web server.

For other advisories, apply the same method to the affected component: framework server, image-processing library, database extension, system package or build tool.

Keep this inventory available to the people on call. A spreadsheet nobody can access when the original administrator is unavailable is a fragile response plan.

A production patch checklist

The checklist below is an operating template, not a substitute for the component vendor's instructions. Apply it to systems you own or are authorized to administer.

1. Decide what needs immediate containment

Confirm affected versions and configurations against current authoritative guidance. Identify internet exposure, sensitive data and privileged access. If a safe update is not immediately available, decide whether to restrict access, disable an affected feature or take a service offline while the owner works through the fix.

Temporary protection needs an owner and a review deadline. Do not silently relabel a workaround as remediation. For PHP2Shell, the official advisory says interim measures do not provide a complete solution. Avoid copying isolated configuration changes without their operational trade-offs.

2. Prepare the replacement and recovery plan

Use trusted packages and build inputs. Record the source revision and artifact identity. Check compatibility with the application's extensions, configuration and important workflows.

Confirm that relevant backups can be restored. A successful backup job is not evidence that recovery works. If a database migration is involved, document whether the old application can safely run against the changed schema.

For a managed host, ask for the package or runtime evidence and rollout coverage that applies to your service. “Our infrastructure is patched” needs to include the environment you actually use.

3. Deploy, then replace affected running processes

Installing a package on disk may not replace already-running processes. Updating an image tag may not replace existing containers. Restart or replace the relevant workers and services according to the vendor's instructions, and confirm the rollout covers every active instance.

Include autoscaling templates and scheduled tasks. Otherwise, a later scale-up or nightly run can recreate an old environment after the immediate rollout appears complete.

4. Verify the fix is loaded and the application still works

Keep two kinds of evidence together:

• Security-update evidence: the running service maps to the approved fixed package or artifact, with replacement or restart records for the affected processes.
• Application evidence: representative requests and background tasks still produce their expected results, including failure and permission checks.

A shell's version command does not prove the web server uses the same executable. A passing homepage does not prove the queue worker restarted. Verify from the actual service context using appropriately restricted administrative tooling. Do not publish a diagnostics endpoint or a public phpinfo() page to make checking convenient.

Do not run a public exploit against production just to obtain a green result. Any intrusive validation needs an explicit scope and a safe environment. Package provenance and running-process evidence are essential even when a scanner reports no finding.

5. Review signs of prior compromise separately

Patching removes a known vulnerable path. It does not establish that nobody used it before the update, and it does not automatically remove persistence already created by an attacker.

Preserve relevant logs and investigate suspicious activity with an authorized responder where warranted. Keep the patch decision moving while that investigation proceeds. Record what the available telemetry can and cannot establish.

6. Recover without restoring the vulnerability

A rollback button is not automatically a safe recovery plan. If it restores the vulnerable image, it can reopen the problem you just closed.

Prepare an alternative: a compatible build containing the security fix, a supported vendor backport, a restricted service mode or temporary isolation while you roll forward. Which option is acceptable depends on the application and incident. Agree it before a failed health check creates pressure to restore anything that happens to run.

Proposed staging exercise: measure the whole patch path

Use a disposable synthetic application with fake accounts and no customer data. This is an exercise design, not a test Thunkle has already run or a claim about measured response time.

Give the team a mock advisory about a component in that application. Use a harmless marker change in the replacement build to demonstrate propagation. There is no need to deploy a real vulnerable service or execute an exploit.

Record these timestamps and the evidence at each step:

Include one long-lived worker and one scheduled task. In the scenario brief, deliberately leave one consumer on the old marker and see whether the verification process catches it. Keep the setup transparent to the exercise owner and confined to the disposable environment.

Choose a response objective based on your own service and staffing. Measure elapsed time and hands-on time separately. The useful result is the bottleneck you can fix: missing access, unknown consumers, a slow build, no recovery path or evidence nobody knows how to collect.

This is the same principle as verifying an AI agent's code fix: the claim needs evidence at the point where it matters. For runtime patching, that point is the deployed service.

Get the production gaps reviewed before an emergency

If your app was assembled quickly, the missing work may be deployment ownership and recovery procedures as much as code. An AI assistant can change files without resolving either.

Thunkle can review your application's agreed security boundaries and identify the configuration or workflow gaps that need attention. Our paid security audit provides evidence-backed findings, remediation guidance and a free re-review of agreed fixes. Implementation is quoted separately.

If you already know the update or deployment workflow needs rebuilding, our development service can scope that work. Start by telling us what runs in production, what your team controls and where an update currently gets stuck.

Request a developer review.