PHP2Shell (CVE-2026-109618, CVE-2026-109619): What To Do Now

On 21 October 2026 the PHP project shipped emergency releases for two critical flaws that have been nicknamed PHP2Shell. Both let someone on the internet run commands on a web server that runs PHP, without logging in. PHP is under a huge share of the web, so the news moved fast and the details got messy fast. Some posts said everything was already being hacked. Others said it was only theory.

This article is based on the official PHP advisories, the CISA alert and the research write-ups from the people who found the bugs, cross-checked against each other. It contains no exploit steps. Where sources disagree, or where something is only a claim, the article says so. Status is as of 22 October 2026 and the story is still developing.

Short version

Two bugs in PHP itself: CVE-2026-109618 and CVE-2026-109619. Both score 9.2 out of 10 (CVSS v4.0). Both can lead to remote code execution with no login.
The bugs are in the PHP engine, not in WordPress, Drupal, Laravel or any plugin. Updating your CMS does not fix them. The PHP runtime on the server has to be updated.
Fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older get no normal release, only minimal source backports for 7.4, 8.0 and 8.1.
Apache with mod_php is the highest risk. PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are listed as affected too.
Attack attempts were being seen on release day. No source reports a confirmed break-in at a named victim.
Config workarounds help a little and fix nothing. Patching is the only complete answer, according to PHP’s own advisory.

The story, for anyone who is not a tech person

Picture a big hotel. On every floor there is one room-service desk, and one staff member sits at it all day taking orders from guests, one after another. To stay fast, this person never goes back to the office between orders. They keep a notepad on the desk with quick reminders: towels are in cupboard 4, the guest in room 312 wants breakfast at eight.

That is roughly how a PHP website works. PHP is the engine that builds a web page when you open a site. The staff member is called a worker. Your visit is an order. The notepad is the worker’s short-term memory. And one worker serves many visitors in a row, which matters a lot in this story.

Now imagine a guest who has studied how this desk operates. They place an order so enormous that the staff member runs out of room halfway through, panics, and walks away from the task. In the rush, a few sticky notes stay on the notepad. They point to cupboards that were just emptied and are about to be used for something else. Nobody tidies the notes up.

A minute later a second order arrives at the same desk. The staff member glances at the notepad before starting, follows an old sticky note to a cupboard, and takes out whatever is in there. The clever guest made sure that what is in there is their own instructions. The staff member, trusting the note, does exactly what it says, as if the hotel manager had written it.

That is the first bug in one picture. Order number one breaks something on purpose and leaves a stale pointer behind. Order number two walks into it. Engineers call this a use after free. The result is that a stranger’s instructions run on the server, with the permissions of the web server, and nobody had to log in.

The second trick is quieter. The staff member follows the old sticky note to a cupboard that now holds someone else’s belongings and simply reads them out loud. The Wiz research team showed that this can leak passwords, tokens, API keys and certificates that belonged to other visitors’ requests. The data came back to the attacker inside an ordinary-looking cookie in the web server’s reply.

Why this one is different

Most website break-ins come from a weak plugin, an old theme or a reused password. The site owner can at least point at something and say that is what I forgot to update. Here the weak spot is in the engine under the site. A tidy, fully updated WordPress site on an unpatched PHP is still exposed. Wiz put it plainly: even a minimal application on an affected PHP version is exposed. The PHP team also says that on mod_php a single unauthenticated request can trigger the attack before any of the site’s own code runs. That is why a firewall plugin inside the site cannot be the answer.

What it means around the world

Numbers first, with their sources. W3Techs measures PHP on about 69.3% of the websites whose server-side language is known. That is the basis for the line you may have seen about PHP running 70% of the web. It is a share of sites where the language is known, not of every site that exists.

Exposure estimates vary because everyone counts differently. Security researcher Silas Cutler roughly estimated more than 1.3 million internet-exposed hosts that are potentially vulnerable. A Shodan search by Henk Poley found more than 1.9 million internet-exposed hosts running PHP, which counts PHP hosts, not confirmed vulnerable ones. VirusTotal estimated more than 5.1 million exposed PHP hosts. These are estimates from different methods and they should not be added together.

The software on top of PHP is where most people feel it. Wiz demonstrated unauthenticated code execution against the latest container images of WordPress, Drupal and Joomla. Calif, one of the researchers, showed it against Magento 2.4.9 and ten other PHP applications. Cisco Talos lists WordPress, Drupal, Magento, Shopware, WooCommerce and Laravel among the software that runs on PHP and is therefore in scope, along with PHP sites hosted through cPanel and Plesk.

Hypothetical example, not a reported incident: a small shop sells handmade soap. It runs WooCommerce on shared hosting, where one server holds a few hundred other sites. The shop owner did nothing wrong and cannot log in to the server to update PHP. Their host has to do it. Until the host does, someone who finds that server could try to run commands on it, or read secrets out of its memory, such as the keys that connect the shop to its payment provider. Multiply that by every shared host, agency server and self-managed VPS on the internet and you can see why governments and vendors treated it as an emergency.

Government reaction is easier to confirm than damage reports. The US cyber agency CISA published an alert on 21 October urging immediate patching. The UK’s NCSC told UK organisations to update immediately or take affected systems offline until patched, as reported by BleepingComputer. CERT-EU also published an advisory. The Hacker News additionally reported that some organisations took services offline as a precaution, including BambooHR and several Dutch government services. Neither report has an official statement behind it, so both are unverified.

What it means for you as a normal user

There is nothing to install on your phone or laptop. This is a server-side problem.
A site you use may go down briefly while the owner patches. That is a good sign, not a bad one.
Be careful with emails or messages that suddenly say you must reset your password because of the PHP vulnerability. Criminals love news like this. Go to the site yourself instead of clicking.
Use a different password on every site, so that one leak cannot open your other accounts.

What happened and when

The order below comes from PHP’s own announcements and the researchers’ timelines. Times are UTC where the sources gave them.

Early to mid August: Calif found multiple code-execution paths and reported the first bug to PHP on 11 August, according to Sansec’s summary. Wiz found its first bug on 19 August and reported to the PHP security team on 24 August.
21 September: PHP acknowledged the reports and began a coordinated fix, per Wiz.
20 October: An online post leaked both CVE IDs ahead of the planned disclosure and claimed a 10.0 severity. PHP’s own rating is 9.2, and the PHP Foundation called the 10.0 figure incorrect, as relayed by Sansec. That evening PHP published an advance notice for a critical release and moved it earlier, to Wednesday 21 October at 14:00 UTC.
21 October, early: Cloudflare turned on firewall rules by default ahead of the patch. Chainguard published images containing the fix several hours before the official release. Cloudflare reported early attack traffic.
21 October, around 14:00 UTC: PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 together with two GitHub advisories. CISA published its alert the same day.
21 October, afternoon: Wiz, Calif and others published technical write-ups. watchTowr reported seeing active exploitation attempts against both CVEs.

The two CVEs in technical terms

Both come from the same family of problems. PHP is built so that one worker process handles many requests in a row and many things are kept in memory between steps. When a request dies in an ugly way, for example by running out of memory, some pointers can be left behind that point at memory the request already gave back. A later request on the same worker can trust those pointers. That is the common thread.

CVE-2026-109618: remote code execution through out-of-memory corruption

Advisory: GHSA-w8hw-w9fx-j79w. PHP uses longjmp() to leave a request when it runs out of memory. In some startup contexts the request’s memory is reachable before it has been fully initialised. If an allocation fails at that moment, shutdown can read or branch on invalid state. The advisory says this can lead to unauthenticated code execution as the web worker account.

The advisory says attackers can reach the condition through multipart request parsing, for example by sending requests with no content length limits, too many headers per part, or many empty file fields and deeply nested field names. It states that mod_php is confirmed exploitable with default settings. PHP-FPM is likely susceptible, FrankenPHP probably is too, and LSAPI is plausibly affected but not validated.

The fix removes longjmp() for out-of-memory handling. A soft limit now marks the request to stop at the next safe point in the engine, and a higher hard limit ends the process. A side effect, noted by The Hacker News, is that hitting the hard limit ends the process and skips shutdown handlers, so after patching it is worth reviewing your memory settings.

CVE-2026-109619: remote code execution through stale global state

Advisory: GHSA-6wmf-4rv5-p3rp. PHP keeps some global state for errors, sessions, objects and extensions in long-lived workers. If a request is cut short, for example by a fatal error or memory exhaustion, that state can still point to memory the request heap already freed. An operation on a later request that runs before normal initialisation can then use the stale pointer. The advisory says a crafted heap layout can turn that into code execution.

It needs two requests handled by the same worker: a producer that leaves the stale state, and a consumer that uses it. The confirmed consumers are diagnostics raised before request initialisation and the session upload-progress handling. The strongest demonstrated case uses the PHP 8.5 fatal_error_backtraces feature and affects mod_php. The advisory also says other kinds of state are only conditionally exploitable.

What Wiz grouped under the two CVEs

Wiz describes four memory-safety bugs grouped under the two CVEs, and says other variants exist that the patch removes. Their list is below. The Wiz write-up does not give a per-CVE mapping. For the exact mapping, see the two GitHub advisories above.

A use after free in the session upload-progress unserializer, which gives a memory-corruption primitive to a later request on the same worker.
A remote memory disclosure, where stale session ID data is trusted by a later multipart request and the heap contents come back URL-encoded in a PHPSESSID cookie. It works even if the application never calls session_start().
A use after free in the stored backtrace of the last fatal error, which a later request can follow into reclaimed memory.
A type confusion in OPcache, caused by an allocation failure between two steps when compiled scripts are stored in shared memory.

Wiz chained these in different ways to get unauthenticated code execution: the unserializer bug plus the memory disclosure against WordPress, Drupal and Joomla, the backtrace bug against Drupal, and the OPcache bug against WordPress.

Why the score is 9.2 and not 10

Both advisories use the vector CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H. In plain words: reachable over the network, no privileges, no user interaction, with high impact on confidentiality, integrity and availability. The reasons it is not a 10 are attack complexity rated high and an attack requirement that must be present, which matches the two-request, heap-layout nature of the attack. High complexity is not the same as hard in practice, as the researchers showed.

Affected versions and fix status

Both CVEs have the same affected ranges and the same fixed releases. Sources: PHP’s two GitHub advisories, the release announcements, the NVD records, the Canadian Cyber Centre alert, Google Cloud’s guidance and the distribution trackers. Status is as of 22 October 2026. Distribution data changes often.

Upstream PHP releases

PHP 8.5: vulnerable below 8.5.12. Fixed in 8.5.12. Security support runs to 31 December 2029.
PHP 8.4: vulnerable below 8.4.27. Fixed in 8.4.27. Security support runs to 31 December 2028.
PHP 8.3: vulnerable below 8.3.36. Fixed in 8.3.36. Security support runs to 31 December 2027.
PHP 8.2: vulnerable below 8.2.35. Fixed in 8.2.35. Security support ends on 31 December 2026.
PHP 8.1, 8.0 and 7.4: considered vulnerable. These branches are end of life, so there is no regular release. The PHP security team published minimal source backports for them, meant for people who build from source.
PHP 7.3 and older, down to 5.4: affected according to the researchers. Wiz says every version back to 5.4 is affected, Cisco Talos says every build since 5.4, and Google Cloud says all versions from 5.4 through 8.5.11. The PHP project gives no fix for these. Calif traced the earliest vulnerable code path to PHP 5.4.0.
Anything older than 5.4: no source states whether it is affected. It is long unsupported regardless.

The PHP advisories give explicit ranges only for the four supported branches, and they say PHP 8.1 and older no longer receive updates. The NVD records for both CVEs say the same thing in a different way: the 8.2 range has no lower bound, so it covers every version below 8.2.35, and the 8.3, 8.4 and 8.5 ranges start at x.0. NVD published both records on 21 October 2026 at 14:17 UTC.

Both release announcements and the advisories say each fixed release closes both CVEs. Note: the PHP changelog page lists the 8.5.12 and 8.4.27 entries under the date 22 October, even though the releases and announcements are dated 21 October. That looks like the original embargo date left in the changelog, and it does not change the fix.

Severity scores, because three different numbers are circulating

PHP security team: CVSS v4.0 score 9.2 for both CVEs. This is the official one.
NVD (the US national vulnerability database): CVSS v3.1 score 9.8 for both CVEs, as its primary score. v3.1 and v4.0 are different scoring systems with different rules, so the numbers are not comparable.
Red Hat: rates CVE-2026-109618 Important with a CVSS v3.1 score of 8.1, because it counts the attack complexity as high.
The leaked 10.0: an early claim that the PHP Foundation called incorrect.

Linux distributions

Distributions often fix a vulnerability without moving to the new upstream version number. So a server that still says PHP 8.1.2 or 8.3.6 may be fixed, and a version number alone proves nothing either way. Tracker status as of 22 October 2026:

Debian: bookworm (php8.2) fixed in 8.2.35-1~deb12u1 and trixie (php8.4) fixed in 8.4.27-1~deb13u1, both through the security archive. The unstable and testing branches (sid and forky) were still listed as vulnerable at 8.4.26-1. Bullseye is not listed in the tracker.
Ubuntu 26.10: php8.5 fixed in 8.5.9-0ubuntu2.1.
Ubuntu 26.04 LTS: php8.5 fixed in 8.5.4-0ubuntu1.5.
Ubuntu 24.04 LTS: php8.3 fixed in 8.3.6-0ubuntu0.24.04.13.
Ubuntu 22.04 LTS: php8.1 fixed in 8.1.2-1ubuntu2.28. This is a backport onto a branch upstream no longer supports.
Ubuntu 20.04, 18.04, 16.04 and 14.04: fixed only through Ubuntu Pro or its legacy support add-on, in php7.4 7.4.3-4ubuntu2.29+esm5, php7.2 7.2.24-0ubuntu0.18.04.17+esm14, php7.0 7.0.33-0ubuntu0.16.04.16+esm22 and php5 5.5.9+dfsg-1ubuntu4.29+esm18. Without that subscription, those systems should be treated as unpatched.
Red Hat: bulletin RHSB-2026-013 rates both Important and lists RHEL 10, 9 and 8 and OpenShift Dev Spaces 3 as directly affected. It says RHEL 7 and earlier ship PHP versions that are not affected, which conflicts with the researchers’ claim of 5.4 and later. The conflict is unresolved, so treat Red Hat’s statement as applying to Red Hat’s own builds only. As of its last update on 21 October at 17:08, some updates were available and more were in progress, and mitigation guidance was still being prepared. Container images built on RHEL or UBI need a rebuild once the base image updates.

No status page was available for Amazon Linux, Fedora, SUSE or Alpine’s own tracker. Check your vendor’s advisory page for the CVE IDs.

Containers, cloud and hosting platforms

Docker official php image: Published tags exist for 8.5.12, 8.4.27, 8.3.36 and 8.2.35 in the cli, fpm and zts variants on Debian bookworm and trixie and on Alpine 3.23 and 3.24, built between 21 and 22 October. A tag you pinned last month does not change, so you must rebuild and redeploy your own images.
Google Cloud: App Engine standard patched supported runtimes (PHP 8.2 and newer) automatically. App Engine flexible, GKE and Marketplace solutions are not patched for you. Cloud Run and Cloud Run functions are patched only where automatic base image updates are on. PHP 5.5, 7.2, 7.3, 7.4 and 8.1 runtimes will not be patched and must move to 8.2 or newer.
Laravel Forge: its automatic security updates do not patch PHP, because Forge installs PHP from a separate package repository. You update PHP per server yourself and then restart long-running processes such as queue workers, Horizon and Octane.
Third-party repositories: the Remi repository did not have updated packages on release day, according to Huntress and Sansec. Check whether yours has caught up before relying on it.
Bundled PHP: control panels, vendor appliances and Windows applications that ship their own PHP can be affected even if you never installed PHP yourself.

Which servers are in scope

PHP lists PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. The advisory says mod_php is the confirmed case with default settings. FPM is likely susceptible to CVE-2026-109618, FrankenPHP probably is too, and LSAPI is plausibly affected but not validated. For CVE-2026-109619, code execution was demonstrated on both mod_php and FPM, with the FPM path depending on an operation in the running application. In short, assume everything that serves web requests is affected and patch it.

What an attacker gets

Code execution as the web worker account. That usually means the ability to read the site’s files, including config files with database passwords, and to drop a web shell. It does not automatically mean root on the machine, but a foothold on a server is a serious problem on its own.
Secrets from memory. The disclosure path can return data belonging to other requests: passwords, session tokens, API keys, certificates.
A launchpad. From a web worker an attacker can try to reach databases and internal services on the same network.

What is confirmed, and what is not

Confirmed

PHP’s own advisory confirms full code execution over HTTP against mod_php with default input and memory limits.
Wiz demonstrated code execution against current WordPress, Drupal and Joomla images, and a separate memory disclosure.
CISA says the flaws allow unauthenticated code execution and affect PHP installations serving web requests.
watchTowr reported active exploitation attempts against both CVEs, and Cloudflare reported attackers changing payloads to get around its rules.

Not confirmed, or disputed

A confirmed compromise of a named victim. Sources report attempts, not a verified breach. watchTowr’s head of threat intelligence was quoted by SecurityWeek saying nobody had succeeded so far, with the expectation that this would not last long.
CISA’s own exploitation status. CISA’s alert says it had not observed exploitation at the time of publication. As of the coverage reviewed, neither CVE was in the Known Exploited Vulnerabilities catalog, and CISA’s page does not state KEV status.
Public exploit code. Sources disagree. The Canadian Cyber Centre says a proof of concept is publicly available. Per Sansec, the PHP Foundation said it had not identified any functional public exploit at release, and that code circulating online is unverified. Either way, do not download and run random proof-of-concept code, because it can carry malware.
The 10.0 score. That was a pre-release figure. The official score is 9.2.
PHP-FPM. PHP considers FPM susceptible to the out-of-memory bug, but a complete FPM exploit for it had not been shown. For the stale-state bug, code execution was shown on FPM, though it depends on an operation in the running application. Patch FPM too.

How to fix it

Step 1: find every PHP you run

CISA specifically notes that PHP is often hidden inside other software, so start with a proper inventory, internet-facing systems first. On a server, check the version and the way PHP is served:

php -v
php -i | grep -i 'Server API'
apachectl -M 2>/dev/null | grep -i php
php-fpm -v

The CLI version can differ from the one your web server uses, so check the web-facing runtime as well, for example with a temporary page that prints the version, then delete it. For Docker, check every image that runs PHP, not just the one you remember:

docker run --rm your-image:tag php -v

Step 2: update PHP to a fixed release

Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install your distribution’s patched package. Package names and service names differ by distro, so use your own package manager and check the changelog for CVE-2026-109618 and CVE-2026-109619. On release day some third-party repositories, including the Remi repository, did not have updated packages yet, so check whether yours does before relying on it.

Then restart every PHP worker and web server process. This is the step people skip. A worker that is still running keeps the old code in memory, so a package that says patched on disk does not protect a process started last week.

Step 3: if you cannot patch today

PHP’s wording is that these steps reduce exposure to specific attack paths but do not make an installation safe. Treat them as a bridge of hours, not weeks.

Set session.upload_progress.enabled=0 in php.ini, the FPM pool or server config that applies before request parsing, then restart all workers. Do not rely on ini_set() or .user.ini.
On PHP 8.5, set fatal_error_backtraces=0 and restart workers.
For CVE-2026-109618, set memory_limit=-1 in a way applications cannot override, such as php_admin_value. Be aware this removes a safety net, so watch the server’s memory. A container or cgroup memory limit is a partial alternative. Do not use RLIMIT_AS or RLIMIT_DATA, because they can trigger the same failure.
Keep post_max_size low, with upload_max_filesize below it, and enforce limits on request size, parts, headers and nesting at the web server or proxy. If your application does not use multipart uploads, block multipart requests at the front end.
Consider pm.max_requests=1 for FPM. It cuts worker reuse, which goes at the two-request condition the attack needs, at a real performance cost.
If the system is internet-facing and unsupported, CISA’s advice is to take it offline until it is updated. A WAF may add some protection, and Cloudflare’s rules are explicitly described as a stopgap that only covers traffic going through Cloudflare.

Step 4: after patching

Restore a sensible finite memory_limit and confirm your running workers use the patched runtime.
Keep session.upload_progress.enabled=0 if you do not use upload progress bars.
Rotate secrets if you have any sign of exposure. Memory disclosure leaves no obvious trace, so on a high-value server it is reasonable to rotate database passwords and API keys as a precaution. This is a precaution, not a vendor requirement.

Step 5: look for signs of trouble

Exploitation happens below the application, so your normal app logs may show very little. Wiz and Huntress suggest looking for:

Unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses.
Unusually large or malformed PHPSESSID cookies in responses.
PHP worker processes restarting for no clear reason.
Web server or PHP processes (php-fpm, php-cgi, httpd, apache2) starting shells, interpreters or download tools such as sh, bash, python, curl or wget.
New files in web roots, new cron jobs and new accounts you did not create.

Huntress adds that clean logs do not prove you were not hit, and PHP’s own advisory says the same about auditing logs. If you find activity, isolate the server and keep the web server and PHP logs before you change anything.

If you are not the one running the server

Managed WordPress or shared hosting: you cannot patch PHP yourself. Check your host’s status page or ask support whether they have deployed the fix and restarted workers. Do not just update WordPress and assume you are done.
A developer or agency: send your clients one clear message with the fixed versions and ask each host the same question.
On PHP 8.1 or older: you are on a version PHP no longer supports. Plan the upgrade now, and in the meantime reduce exposure with the steps above or put the site behind a VPN or access control.

Why this story is bigger than one patch

The points below are partly interpretation and are kept separate from the facts above.

The embargo broke. The details leaked a day before the planned release, and by report a video of a working proof of concept was posted by mistake. That forced the release earlier, which is why many teams got a few hours of notice instead of a few days.
AI played a role in the exploit work. Wiz credits AI models with helping adapt exploits across versions, configurations and memory layouts. This is Wiz’s claim and has not been independently measured. It fits a pattern where the time between a bug being found and being usable keeps shrinking.
The warning signs were old. The Hacker News reports that a PHP core developer noticed signs of the out-of-memory problem during PHP’s 2024 external audit, but no concrete route to code execution was found then, and competing fix proposals stalled for months. The PHP Foundation reportedly called the delay a structural failure of its decision process and resources. This is as reported by The Hacker News.

Takeaway: patching the application layer is not enough. Know which runtime sits under every service you own. CISA’s first step is an inventory of every system running PHP and its version, and that inventory is the real work.

Frequently asked questions

Is PHP2Shell a real vulnerability?

Yes. It is two CVEs, CVE-2026-109618 and CVE-2026-109619, published by the PHP project in its own security advisory and GitHub advisories on 21 October 2026, and acknowledged by CISA.

Do I need to update WordPress?

Updating WordPress, Drupal or Laravel does not fix PHP2Shell, because the bugs are in PHP itself. The PHP runtime on the server has to be updated by you or your host. Keep your CMS updated for other reasons.

Which PHP versions fix it?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older are no longer supported, with minimal source backports available for 7.4, 8.0 and 8.1. Distribution packages may carry the fix under an older version number, so check the changelog.

Is it being exploited right now?

Security firms reported exploitation attempts on release day. No confirmed compromise of a named organisation had been reported as of 22 October 2026. Assume it is a matter of when for unpatched internet-facing servers, since details and unverified proof-of-concept code are circulating.

Can I just use a firewall or change a setting?

A WAF and the listed settings can reduce exposure to some attack paths. PHP says they do not make an installation safe, and that updating is the only complete fix.

Does CISA say to take servers offline?

CISA says organisations that cannot update immediately, or that run PHP 8.1 or earlier, should take PHP-based systems offline until patched or updated. It also says a WAF may offer some interim protection.

How many sites are affected?

Nobody knows exactly. PHP is on about 69.3% of sites whose server-side language is known, and independent estimates of exposed hosts range from about 1.3 million potentially vulnerable to more than 5 million PHP hosts, depending on the method. Treat all of them as estimates.

Sources and method

Sources: PHP’s announcements and the two GitHub advisories, the CISA alert, write-ups from Wiz, Cisco Talos, Qualys, Tenable, Huntress, Sansec and watchTowr, and news coverage for the timeline. Where a secondary source conflicted with the advisories, the advisories were used. Statements about attacker capability are the vendors’ and researchers’ findings, attributed in the text; the exploit was not reproduced. Single-source claims are labelled as reported. Details may change as patches and information arrive.