Abstract

Software vulnerabilities become public. Attackers learn about them at the same moment as everyone else. Maintainers then have to work out whether they are exposed, prepare a fix, test it and deploy it. Each of those steps takes time, and the time between public disclosure and a deployed fix is when systems are most at risk.

AI is making vulnerability discovery and analysis faster. If discovery speeds up and remediation does not, that window gets more dangerous. This paper proposes an autonomous, permissioned patching agent. It watches public advisories, finds opted-in open-source repositories that pin affected versions, prepares deterministic fixes, tests them in the repository's own CI, opens pull requests, and publishes evidence of every action.

Why this exists

Every vulnerability follows roughly the same lifecycle:

Bug exists
Discovery
Coordinated disclosure
Patch release
Public knowledge
Maintainer response
Real-world remediation

The dangerous interval runs from public knowledge to real-world remediation. In plain terms: once a problem is announced, anyone can read about it, but the fix only protects a website after its maintainer has applied the update. That gap is the vulnerability window. The aim of this project is to make it shorter.

PHP2Shell: the wake-up call

On 21 October 2026 the PHP project published critical security releases addressing CVE-2026-109618^{[nvd-cve-2026-109618]} and CVE-2026-109619^{[nvd-cve-2026-109619]}.

The affected behaviour was in PHP core (php-src), the runtime that executes PHP applications, not in a single framework or plugin^{[php-src-advisories]}. A runtime vulnerability is inherited by every application running on an affected build, however carefully that application was written.

That creates an affected-version problem: maintainers need to know which runtime they actually deploy (a container base image, a distribution package, a CI image), not only which PHP version their code supports. Fixed releases for supported branches at disclosure^{[php-changelog-8]}:

PHP 8.5.12 for the 8.5 branch
PHP 8.4.27 for the 8.4 branch
PHP 8.3.36 for the 8.3 branch
PHP 8.2.35 for the 8.2 branch

Branches older than 8.2 are outside upstream security support^{[php-supported]}. They should not be described as receiving ordinary upstream fixes. Users need to migrate to a supported branch or rely on vendor-maintained packages.

How PHP2Shell worked: a safe explanation

PHP processes each web request using internal runtime state and memory allocated for that request. When the request finishes, the memory is supposed to be cleaned so the next request starts fresh.

Request
Worker
Request memory
Application
Cleanup
Response

Some abnormal termination paths, such as certain fatal errors and out-of-memory conditions, could leave internal state inconsistent. A later request handled by the same worker could then interact with state that should have been reset. Memory-safety failures like this can have severe consequences, including disclosure of sensitive memory and, in some environments, code execution.

This paper deliberately leaves out triggering conditions, request construction and memory-layout details. None of them are needed to understand or carry out the defensive response, which is to update.

Why AI matters

AI-assisted security research can cut the time needed to understand large codebases and reason about difficult bug classes. Public accounts of PHP2Shell describe such assistance. Specific attributions will be cited once their primary sources are confirmed^{[research-pending]} (verification pending).

That creates offensive risk and defensive opportunity at once. The right response is not just “AI is dangerous.” It is: defense must scale with discovery.

The patching bottleneck

After a disclosure, each maintainer independently has to:

read the advisory
understand which packages are affected
inventory their repositories
determine actual exposure
identify the safe version
modify the dependency or image
run tests
review compatibility
open a pull request
review it
merge
deploy

Across thousands of projects, most of whose maintainers are volunteers, the same mechanical work gets repeated thousands of times. Much of it is deterministic, and deterministic work can be automated safely.

The proposed agent

Ingestion
Normalization
Version reasoning
Repository matching
Authorization
Patch generation
Testing
PR submission
Verification
Public proof

Advisories come from NVD, GitHub Security Advisories and CISA KEV and are normalized into one schema that keeps provenance for each provider. Version reasoning compares affected ranges against authoritative fixed releases. Matching inspects only files in opted-in repositories. Every state transition is stored as an event and streamed publicly.

Authorization model

The agent writes only to repositories that explicitly opted in by installing the GitHub App. A .patchbot file can narrow its behaviour further: which severities, which patch types, whether PRs are drafts, and whether CI and human review are required.

No mass unsolicited pull requests.
No modification of repositories without authorization.
No scanning of arbitrary hosts or private systems.
No pushes to default branches.

Safe patching

The first patch categories are deterministic and low-risk:

Docker base-image version updates (php:X.Y.Z-variant)
Compose file image updates
CI image and php-version updates
composer.json config.platform.php pins
Lockfile refreshes (planned)
Deterministic configuration migrations (planned)

Changes stay on the same branch, from a patch release to a later patch release. Cross-branch upgrades and source-code patches need a higher confidence threshold and, by default, human review.

Verification

A patch is not trusted just because it was generated automatically. Every patch passes through:

Static validation
Build
Test
CI
Policy
Human review (if configured)
Merge verification

Static validation enforces a file allowlist, an unchanged line count, a diff-size limit, secret detection and dangerous-content detection. A merge is recorded only from a signed GitHub webhook.

Proof of work

This is not blockchain proof-of-work. Here “proof” means engineering output that anyone can verify independently: the GitHub pull request, the commit, the CI result, the merge timestamp, the advisory source, the repository's authorization and, for funding, the transaction signature.

The public ledger contains only REAL records that carry an external verification URL. Simulated development data is structurally excluded from it.

Self-funding infrastructure

Protocol or creator fees may be routed to a publicly visible operational treasury. That treasury may pay for inference, compute, database, indexing, RPC, storage and monitoring.

Any associated token is not equity and is not marketed as an investment. This project promises no yield, no appreciation and no returns.

The agent wallet

The wallet is publicly readable, and the website never holds its private signing key. The treasury page shows inflows, expenses and runway, read directly from the chain.

Runway = liquid operational assets ÷ rolling 30-day average daily infrastructure cost. Speculative future income is never counted. Until 30 days of categorised expenses exist, runway is shown as unavailable rather than estimated.

Threat model

Malicious repositories. Repository content is parsed by deterministic code and never executed on agent infrastructure.
Prompt injection in source files. Phase 1 sends no repository content to a model. See §15.
Malicious .patchbot configuration. A strict schema rejects unknown keys, has no command fields, blocks YAML aliases and caps file size.
Dependency confusion. Only the official php image and versions from php.net release data are proposed.
Webhook spoofing. HMAC-SHA256 verification with constant-time comparison.
GitHub token compromise. Short-lived, installation-scoped tokens and least-privilege permissions. Writes can be disabled with one flag.
Supply-chain poisoning. Changes are limited to version identifiers. Diffs that add URLs, scripts or commands are rejected.
False CVE matches. Only explicit three-part pins are matched. Anything ambiguous goes to human review.
Unsafe generated patches. File allowlist, diff limits and content checks before CI.
Secret exposure. Secret-pattern scanning on every diff. Keys exist only in server environment variables.
Model hallucinations. Deterministic generation in phase 1. Any future model output is treated as an untrusted proposal.
Treasury spoofing. Balances are read from chain RPC and linked to a public explorer, never typed in by hand.

Prompt-injection defense

Repositories contain untrusted data. The agent treats all repository content as data, never as instruction. Text in a README, issue, comment, source file, package manifest or commit message that tries to change the agent's behaviour has no effect.

Isolation is structural. The phase-1 matcher and patcher are fixed code with fixed patterns. If a model is introduced, it will get repository content only inside clearly delimited data fields, its output must parse into a strict schema (file, line, from-version, to-version), and that output goes through the same safety validator as deterministic patches.

Failure modes

The system can misclassify exposure, fail tests, propose an upgrade that is incompatible with a project, suffer upstream API downtime, lack authorization, or meet a build system it does not support.

In every case it fails safe: no PR is opened, the attempt is recorded with its reason, and where appropriate the status becomes HUMAN REVIEW REQUIRED. Outages show up on /status rather than being hidden.

Economics

Operating economics are reported per unit: cost per repository analysis, per patch attempt, per successful patch and per merged patch. These figures are computed only from recorded expenses and recorded outcomes. Where no data exists, none is shown.

This paper makes no token-price projections.

Roadmap

Phase 0: PHP2Shell demonstration. Status: IN PROGRESS. Educational site, fixed-version data, deterministic patcher, public endpoints.
Phase 1: Deterministic dependency remediation. Status: IMPLEMENTED. Scheduled worker, GitHub App PR flow, CI and merge tracking are built. Whether they are operating right now is reported live on /status.
Phase 2: Multiple ecosystems. Status: PLANNED.
Phase 3: Repository-specific patch generation. Status: PLANNED.
Phase 4: Organization-level fleet protection. Status: PLANNED.

Limitations

Updating a pinned version in a repository does not update running deployments. Operators still have to redeploy.
Runtimes installed from OS packages (apt, yum, apk) or managed hosting are not visible from a repository.
Phase 1 handles only explicit PHP version pins. It does not analyse application code.
Without a configured database the ledger is held in memory and lost on restart. /status reports this.
Coverage depends on opt-in. Most projects will not be covered.
Third-party research claims are cited only once confirmed.

Conclusion

AI shortens the path from source code to vulnerability discovery. Defense has to shorten the path from disclosure to remediation.

The objective is not autonomous exploitation. It is autonomous repair: permissioned, tested, and publicly verifiable.

Citations resolve to /sources.