Pentr blog

PHP2Shell: what CVE-2026-109618 and CVE-2026-109619 are, and how to confirm you're fixed

2026-10-22T00:00:00Z

On Tuesday 20 October, details of two remote code execution bugs in PHP leaked before their planned disclosure on the 22nd. PHP moved its release forward a day. On Wednesday 21 October, at around 14:00 UTC, it published 8.5.12, 8.4.27, 8.3.36 and 8.2.35. By that afternoon watchTowr was reporting exploitation attempts against both bugs. Cloudflare had already seen attacks that morning, before a fix existed.

The pair is being called PHP2Shell. Both are rated 9.2 under CVSS v4.0. The 10.0 that circulated with the leak was not PHP's score. An attacker can reach either bug with an ordinary web request and no login. Both sit in the interpreter itself, not in WordPress, Laravel or anything else running on top. If a server of yours runs PHP and answers HTTP requests, this applies to you.

What the two bugs are¶

CVE-2026-109618 is in PHP's out-of-memory handling. If PHP runs out of memory at the wrong moment while setting up a request, some internal request data is left half-built. The cleanup code that runs afterwards doesn't know this and treats the data as valid. An attacker who can control when memory runs out can turn that into code execution.

CVE-2026-109619 is a use-after-free: state that belongs to one request outlives the memory behind it. One confirmed attack path goes through session upload progress. That feature is on by default, and it touches session handling before PHP has finished setting up the request.

Every PHP release from 5.4 up to 8.5.11 is affected. So is every way of running PHP for the web: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP considers mod_php the worst case. There, the bug can fire before your application code has even loaded, so nothing you wrote can stand in the way.

How to remediate¶

Upgrade. That is the fix, and PHP's own advisory says there is no complete mitigation.

If you build PHP from upstream source, move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and restart every worker.

If PHP comes from your distribution, install the vendor's updated package. Don't rely on the version number, because distributions backport fixes and often leave it unchanged. Check the package changelog for the CVE IDs instead:

# Debian / Ubuntu
apt changelog php8.2-fpm | grep -E 'CVE-2026-10961[89]'

# RHEL / Alma / Rocky
rpm -q --changelog php | grep -E 'CVE-2026-10961[89]'

If PHP runs in containers, rebuild from a patched base image and redeploy. A running container does not update itself.

If you can't patch tonight, there are two partial measures:

For CVE-2026-109619: set session.upload_progress.enabled = 0 and restart every worker. On PHP 8.5, also set fatal_error_backtraces = 0. This closes one known attack path and does nothing at all for CVE-2026-109618.
For CVE-2026-109618: move memory-limit enforcement from PHP to the server level and keep upload sizes low. This narrows the bug but does not close it. It is also a change for whoever runs the server, not for the application team.

PHP 8.1 and older are past end of life and get no upstream fix. If you run one of them from a distribution with extended support, check whether the vendor has backported the patch. If you built it yourself, or your host doesn't say, assume you are vulnerable. This is the uncomfortable part of PHP2Shell: the exposure is largest on the systems nobody has touched in years.

How you know you're fixed, and what a test can't tell you¶

Checking from the outside is harder than it looks. An X-Powered-By: PHP/8.1.2 header doesn't prove a server is vulnerable, because a backported fix keeps the old version string. A missing header doesn't prove it's safe either, since expose_php may simply be off. The reliable check happens on the host itself: the package changelog, php -v for upstream builds, and confirming that every worker restarted after the upgrade.

Nobody should confirm the fix by running the exploit against production. These are memory-corruption bugs, and a failed attempt can crash workers or leave a process in a state no one wants to debug on a Thursday night. We don't do it in Pentr, and we wouldn't recommend a tester who does.

What an external test does well is answer the question that eats the first day of any advisory: where is PHP running at all? A Pentr run lists the in-scope hosts that expose PHP and flags the end-of-life versions and risky configurations it can see from outside. Each engagement gets its own sealed evidence locker. The run before you patch and the retest after it give you two signed, independently verifiable records: one showing the exposure, one showing it closed. That pair is what you hand to a customer or an auditor who asks when it was fixed.

If you ship software that bundles PHP, the Cyber Resilience Act applies too. Since 11 September 2026, manufacturers must send an early warning within 24 hours of becoming aware of an actively exploited vulnerability in their product, and a fuller notification within 72 hours. Whether PHP2Shell triggers that duty depends on your product and on how the bug is being exploited. Either way, a dated record of when you found the exposure and when you closed it is what that clock is measured against.

Could a pen test have caught PHP2Shell before Tuesday? No. Researchers at Wiz found these bugs by digging into the interpreter, and no external test of your application would have found them. What regular testing changes is your starting position. If you already knew which hosts ran PHP and which were still on 7.4, Wednesday was a patching day rather than a search.

If you do one thing tonight, run the changelog check above on every PHP host, and turn off upload progress on any host you can't upgrade yet.

Pruebas de penetración en el ENS: qué evidencia espera el auditor en sistemas MEDIA y ALTA

2026-10-20T00:00:00Z

Si gestionas un sistema de categoría MEDIA o ALTA, hay una fecha que pesa más que cualquier ley en tramitación: la de tu próxima auditoría del Esquema Nacional de Seguridad. Este artículo trata de esa fecha. En concreto, de qué papel juegan las pruebas de penetración en ella y por qué el informe en PDF que entrega el proveedor suele dejar huecos que el auditor acaba encontrando.

NIS2 puede esperar. El ENS, no¶

España tenía que haber transpuesto la Directiva NIS2 antes del 17 de octubre de 2024. El Consejo de Ministros aprobó el anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad el 14 de enero de 2025, y la ley no ha llegado a publicarse en el BOE. El 8 de julio de 2026 la Comisión Europea llevó a España ante el Tribunal de Justicia de la UE por el retraso. Con la disolución de las Cortes el 6 de octubre y las elecciones del 29 de noviembre, el texto queda pendiente de la próxima legislatura.

Habrá ley, y traerá obligaciones nuevas para miles de entidades. Pero mientras tanto, para las administraciones públicas y para las empresas privadas que les prestan servicios, la obligación exigible hoy es el ENS (Real Decreto 311/2022). Tiene medidas concretas, categorías y auditorías con fecha. Es, con diferencia, el marco que antes vas a tener que demostrar.

Qué dice el ENS sobre las pruebas¶

El ENS no tiene una medida titulada "pentest". La exigencia de buscar y corregir vulnerabilidades está repartida por varias medidas del Anexo II, y cambia con la categoría. La categoría sale del impacto sobre las cinco dimensiones (disponibilidad, integridad, confidencialidad, autenticidad y trazabilidad), y cada medida añade refuerzos según sube.

Las medidas que más pesan en las pruebas técnicas son estas:

Medida	Qué pide	MEDIA	ALTA
op.mon.3 R2	Vigilancia que determine la superficie de exposición a vulnerabilidades y deficiencias de configuración	Sí	Sí
op.mon.3 R6	Inspecciones periódicas, y tras incidentes que revelen vulnerabilidades: verificación de configuración, análisis de vulnerabilidades y pruebas de penetración	No	Sí
mp.s.2 R1 / R2	Auditorías de seguridad de las aplicaciones web: de caja negra (R1) o de caja blanca con herramientas automáticas de detección de vulnerabilidades (R2)	R1 o R2	R2
mp.sw.2 R1, op.exp.4 R1	Pruebas antes de pasar a producción, en un entorno aislado o de preproducción	Sí	Sí

Dos detalles merecen atención. El primero: la única mención literal a las pruebas de penetración como obligación de una categoría está en op.mon.3 R6, y solo aplica a ALTA. En MEDIA, la exigencia llega por la vigilancia de la superficie de exposición y por las auditorías de las aplicaciones web, no por la palabra "pentest". El RD 3/2010 sí pedía análisis de vulnerabilidades y pruebas de penetración en MEDIA antes de la entrada en servicio; el RD 311/2022 lo reorganizó, y algunos resúmenes siguen citando el texto antiguo.

El segundo: el Anexo II no fija la frecuencia. op.mon.3 R6 dice "periódicamente", y mp.s.2 deja la frecuencia de las auditorías al procedimiento de auditoría de la entidad. Esa frecuencia la decides tú, y el auditor comprobará que está definida y que se ha cumplido.

Nuestra recomendación es sencilla: lee las medidas aplicables con sus refuerzos para tu categoría, y apóyate en las guías CCN-STIC correspondientes. No te quedes con el resumen de un proveedor, incluido este.

Qué mira el auditor¶

Los sistemas MEDIA y ALTA necesitan una auditoría para certificar su conformidad (artículo 38). La auditoría ordinaria se repite al menos cada dos años, y una modificación sustancial del sistema obliga a una extraordinaria (artículo 31). Cuando el auditor llega a las pruebas técnicas, suele hacer cuatro preguntas:

¿El alcance de las pruebas coincide con el sistema certificado? Es decir, con los activos que figuran en tu inventario y tu declaración de aplicabilidad.
¿Cuándo se hicieron? Y si fue antes o después de los cambios relevantes del sistema.
¿Qué se encontró y qué se hizo con ello? El hallazgo tiene que llevar a una corrección, y la corrección a una comprobación.
¿Puedo comprobar algo de lo que pone aquí? No es habitual que lo pregunte en voz alta, pero es lo que intenta al muestrear.

Dónde falla el informe en PDF¶

No es un problema de calidad del pentester. Es un problema de formato. Estos son los huecos que más se repiten:

Alcance genérico. "Infraestructura expuesta de la entidad" no se puede cruzar con un inventario de activos. El auditor quiere rangos, dominios y aplicaciones concretos.
Fechas que no encajan. Un informe de marzo para un sistema que cambió de proveedor de nube en junio describe otro sistema.
Hallazgos sin cierre. El informe lista lo encontrado, pero la corrección vive en un ticket y la verificación en un correo. Nadie las ha juntado.
Capturas sin contexto. Una imagen de una respuesta no dice qué petición la produjo, contra qué máquina ni cuándo.

Cada uno de estos huecos se suele tapar con conversaciones durante la auditoría. Funciona, pero consume tiempo de las dos partes, y deja la conformidad apoyada en explicaciones en lugar de en evidencias.

Un registro en lugar de un informe¶

En Pentr, la evidencia de una prueba no es un documento redactado después, sino el registro de la propia ejecución. La primera entrada es el alcance declarado (rangos y dominios dentro y fuera de alcance) junto con la autorización. Después vienen, en orden, cada petición y respuesta, cada comando con su salida y cada captura, etiquetados con la fase y con la medida del ENS con la que se relacionan. Cada entrada está encadenada con la anterior mediante su huella SHA-256, y la cadena se firma al cerrar la ejecución.

Para el auditor, eso cambia dos cosas. El alcance deja de ser una afirmación en la primera página y pasa a ser la primera entrada de la cadena, sellada con todo lo demás. Y la verificación no depende de nosotros. Con el registro exportado y la clave pública, pentr-verify comprueba en su propio equipo, sin cuenta y sin conexión, que no se ha modificado nada.

Cuando se corrige un hallazgo, la nueva comprobación se añade al mismo registro. El hallazgo, la corrección y su verificación quedan juntos, que es justo lo que el auditor intenta reconstruir.

Lo que Pentr no sustituye¶

Un registro firmado de las pruebas es una evidencia más. No hace el resto del trabajo:

La categorización del sistema y el análisis de riesgos son tuyos.
La declaración de aplicabilidad y la política de seguridad, también.
La auditoría la hace una entidad de certificación acreditada. Nosotros le damos material, no la conformidad.
Lo que no es accesible por red queda fuera: revisión de código, hardware, procesos internos.

Antes de la próxima auditoría¶

Una lista corta, en el orden en que la haríamos:

Confirma la categoría de cada sistema y qué medidas y refuerzos te aplican.
Define por escrito la frecuencia de las pruebas, ya que el Anexo II no la fija.
Alinea el alcance de las pruebas con el inventario de activos, rango a rango.
Prueba después de los cambios relevantes, no solo en las semanas previas a la auditoría.
Une cada hallazgo con su corrección y con la prueba que la verifica.
Guarda la evidencia de forma exportable y verificable durante todo el ciclo de certificación.
Pregunta al auditor qué formato prefiere antes de la visita, no durante.

El texto consolidado del RD 311/2022 recoge todas las medidas del Anexo II con sus refuerzos. Si quieres ver cómo encaja un registro sellado con las medidas del ENS, la página del ENS lo explica con más detalle.

CRA reporting is live. Know your exposure before the clock starts

2026-10-07T00:00:00Z

On 11 September 2026 the first operational part of the Cyber Resilience Act started to apply. Manufacturers of products with digital elements now have to report actively exploited vulnerabilities and severe incidents through ENISA's Single Reporting Platform. Most of what has been written since is about the reporting itself: who files, through which form, by when.

That matters, and if you have not sorted it out yet, it should be first on your list. This post is about the step before it. The reporting clock starts when you become aware of a problem. How much you already know about your own products decides whether that moment is a surprise.

What applies now¶

Article 14 covers two kinds of event: a vulnerability in your product that is being actively exploited, and a severe incident affecting the security of your product. For an actively exploited vulnerability, the sequence is:

an early warning within 24 hours of becoming aware;
a vulnerability notification within 72 hours, with general information and any mitigations;
a final report within 14 days of a corrective measure being available.

Severe incidents follow the same 24 and 72-hour steps, with a final report within a month. Reports go through the SRP, which forwards them to the CSIRT acting as coordinator for your main establishment and to ENISA. You also have to inform affected users, and in some cases all users.

Two details are easy to miss. First, the obligation covers products already on the EU market, not only new ones. Second, the Commission's guidance says you do not have to report, retroactively, exploitation you already knew about before 11 September.

The rest of the regulation, including the essential requirements and the vulnerability handling processes in Annex I, applies from 11 December 2027.

What Article 14 does not ask¶

The reporting duty is narrower than it sounds. It is not about every vulnerability you have. It is about vulnerabilities someone is actually exploiting, and incidents that actually affected security.

This means a weakness found in your own test is not, by itself, an actively exploited vulnerability. If your pen test finds an SSRF in an API, you fix it. You do not file it with ENISA, unless you also find evidence that someone else got there first. Where that line falls for a specific case is a question for your counsel, not for a vendor's blog. But it is worth being clear that testing does not create reporting obligations on its own.

The uncomfortable part is legacy¶

New products can be designed for the CRA. The harder problem is what is already out there: a device line sold five years ago, firmware whose original team has moved on, a cloud backend that three product generations still talk to. The CRA counts a product's remote data processing as part of the product, so that backend is in scope too.

For these products, the first sign of trouble is often external: a CSIRT, a researcher, a customer's security team, a threat report that names your product. At that point the clock is already running, and the first question is what you knew about that part of the system before today.

If the answer is "nothing recent", the 24 hours go into finding out what the system even exposes. If the answer is a dated record of what was tested, what was found and what was fixed, the 24 hours go into the question that matters: is this new, or is it something we already understood?

A record cuts both ways¶

We should be honest about one thing. A dated record of your tests shows what you knew and when. If a test found a problem in March and it was still open in September, the record shows that too.

We do not think that is an argument for not looking. It is an argument for fixing what you find, and for keeping the retest in the same record as the original finding. A finding, a fix and a confirmed retest is about the best evidence of diligence a manufacturer can show. An unexamined system is not a defence.

December 2027 is closer than it looks¶

From 11 December 2027, Annex I Part II requires manufacturers to apply effective and regular tests and reviews of their products' security, along with an SBOM, a coordinated disclosure policy and a working update process. Conformity assessment will look for evidence of all of this in your technical documentation, and the CRA expects that documentation to be kept for at least ten years or the support period, whichever is longer.

Two words in that requirement are worth reading slowly. "Regular" suggests a single annual test will be hard to defend for a product that ships updates every month. "Effective" suggests the tests have to reach the parts of the product that matter, not only its marketing site.

Where Pentr fits, and where it does not¶

Pentr tests what is reachable over a network: hosts, ranges, web applications and authenticated APIs. For many manufacturers, that is the cloud backend and the device-facing APIs, which is often where legacy risk sits. Each run produces a sealed record of what was tested, found and retested, which you can keep as part of your technical documentation.

Pentr does not test firmware or hardware, file reports on the SRP, generate SBOMs or perform conformity assessment. If you need those, you need other tools and, for some product classes, a notified body. Also note that our standard retention is one year, so export the locker if you need to keep it for the CRA's ten years.

Before December 2027¶

A short list we would work through, in this order:

List every product on the EU market, including legacy lines and the backends they depend on.
Decide who declares "aware". Name the person and the escalation path that can meet 24 hours on a weekend.
Register on the SRP and confirm which CSIRT coordinates for your main establishment.
Publish a disclosure policy and a contact point, so researchers report to you rather than about you.
Set a testing cadence per product, tied to its release rhythm, and keep each run's evidence with the release it covers.
Plan retention for ten years. Whatever produces your test evidence, make sure it can be exported and still verified later.

The ENISA Single Reporting Platform page has the registration guidance and FAQs. If you want to see what a sealed test record looks like, the locker page walks through one.

Your pen test report is a PDF you have to trust

2026-09-28T00:00:00Z

Most penetration tests end the same way. Testing stops on a Friday, and the following week someone writes a report. A few dozen pages arrive as a PDF: an executive summary, a scope statement, a findings table, and a screenshot for each finding. The auditor reads it, checks the dates and the firm's name, samples two or three findings and files it.

What the auditor cannot do is check any of it. The report is a description of the work, written after the work, by the people who did it. Everything in it is a claim.

That has worked for a long time, and it mostly still works. But it is worth being precise about what is being trusted, because the conditions around it are changing.

What the auditor is actually trusting¶

Take a typical finding: an SSRF in an import endpoint that reaches the cloud metadata service. In the report it appears as a paragraph, a CVSS score and a screenshot of the response. To accept it, the auditor has to trust that:

the screenshot came from the system in scope, on the date stated, and not from a lab or a previous engagement;
the request that produced it was the one described, and nothing was left out of the chain;
the scope page at the front of the report matches what the tester actually touched;
nothing was added, removed or softened between the test and the final version.

None of this is a criticism of pentesters. The format was designed for a reader who trusts the author, and most of the time that trust is earned. The report is a professional opinion, and it is signed by a firm with a reputation to lose.

The strain shows in two places. The first is frequency. PCI DSS expects testing at least annually and after significant changes, and SOC 2 reviewers increasingly want evidence of continuous monitoring. The number of reports grows, and the time anyone spends checking each one shrinks. The second is automation. When part of the work is done by an agent, the auditor's question changes from "do I trust this firm?" to "what did the software actually do?" A PDF written afterwards is a poor answer to that question, however well written it is.

Keep the test, not a description of it¶

The alternative we settled on is simple to state: do not write a document about the test. Keep the test.

In Pentr, every artifact the agent produces is captured at the moment it exists. That means each HTTP request and response, each command with its stdout and stderr, each screenshot, and the manifest of what each reconnaissance phase enumerated. Each one is stored as a discrete entry, with a SHA-256 digest of its bytes and metadata recording its position in the run, its kind, the phase, the controls and findings it relates to, and when it was captured.

Each entry's hash also covers the hash of the entry before it:

entry[n].hash = sha256( entry[n-1].hash + sha256(artifact) + metadata )

The chain starts from a value derived from the run's ID, so a chain lifted from one run does not verify under another.

When the engagement ends, whether it completed or was aborted, the head of the chain is signed with an Ed25519 key. Because every entry points back to the one before it, signing the head covers the entire history.

Three properties follow, and none of them depends on anyone's good intentions:

Nothing can be edited quietly. Change one byte of one artifact and its digest changes, which breaks every link after it.
Nothing can be removed or reordered. The chain records order, so a deleted screenshot leaves a gap that verification reports.
Scope is sealed with the work. The signed manifest carries a digest of the run's in-scope and out-of-scope lists and its rules of engagement. Anyone told what the scope was can recompute that digest and compare it. Change the scope after the fact and it no longer matches, so the scope and the work cannot drift apart.

None of these ideas is new. Signed, append-only logs are how certificate transparency works, and how trust service providers keep records that have to stand up years later. We have applied them to a pen test.

Verification that does not involve us¶

A record like this is only useful if the auditor can check it without asking the vendor. If verification means logging into our console, we have only moved the trust from the tester's PDF to our server.

So verification runs offline, against an exported locker, with a public key:

$ pentr-verify pentr-locker-3f9a1c2e.zip --key acme.pem
OK      0  command_log      f869ee4c0b89  -
OK      1  req_resp         2482ffa1be00  -
OK      2  screenshot       075f8e3f22fc  screenshot.png
…
PASS — evidence locker verified

  run          3f9a1c2e-7b44-4d21-9a6e-0c5b8e2d14f7
  artifacts    38
  chain head   af08f99ccd6af021f46396c82a2cd859c6296f32b28af9f2291e6ae7e0ae0bab
  signed by    5f79492518ca52f60086291848a46ef8c9a852f7cb0394509b0fa552541a3d69
  signed at    2026-08-26T01:04:11.229107+00:00

The verifier recomputes every digest, walks the chain and checks the signature. If anything fails, it marks the artifact BAD and says what broke. It needs no account and no network access. The public key should come from the organization through a channel you trust, not from the locker itself. Run without --key, the tool still checks everything, but it says plainly that it has proved the locker is intact, not who signed it. The verifier is open source, so anyone who prefers not to trust our binary can read it, build it and run it in their own CI.

What a signature does not prove¶

This is the part vendors tend to skip, and auditors should ask about it.

A valid seal proves the record was not changed after it was sealed. It does not prove the test was thorough, or that the declared scope was the right one. Coverage is still a judgment, and the locker makes that judgment reviewable, not unnecessary.

The timestamps are the ones our runner recorded. They are consistent and chained, but they are not qualified timestamps from an independent authority. For most audits that is enough. If you need more, tell us what your auditor expects.

The signer matters. Today, lockers are sealed with an Ed25519 key that Pentr holds, encrypted at rest, and signs with in software. You can generate that key or upload one of your own, but either way we hold it. A sealed locker cannot be altered without verification failing, but we are technically able to sign on your behalf, and we say so in the documentation and in every locker's README. If what you need is independence from us as the signer, the key should live somewhere we cannot reach. Signing with your own HSM or KMS key, and running the agent on premises, are on the Enterprise roadmap.

A finding is still a judgment. Severity and CVSS are opinions. What changes is that the opinion now sits next to the exact request and response it is based on, so a reviewer can disagree with it on evidence.

What changes in practice¶

For the auditor, sampling a finding stops being a matter of reading a paragraph. They open the artifact the finding points to and read the actual exchange. The control mapping (PCI 11.3.1, ASVS V5, ISO A.8.8) is attached when the artifact is captured, not assembled the week before the audit.

For the security team, less time goes into writing and formatting. A retest after remediation is another sealed entry in the same record, not a new paragraph in a revised PDF.

The PDF does not disappear. Most auditors will still want a summary, and people still need something to read on a train. The difference is that the summary becomes an index to the evidence rather than the evidence itself.

If you want to see what this looks like, the locker page walks through a sealed run, and the verifier documentation shows how to check one yourself.