Facts checked on 9 October 2026 against the CVE record, NVD, Patchstack, Wordfence and Elementor’s changelog. Sources are listed at the end.

What is CVE-2026-32475?

CVE-2026-32475 is a vulnerability in Elementor Pro, the paid add-on to the Elementor page builder for WordPress. It sits in the Forms module, in the File Upload field that lets a visitor attach a document to a form: a CV with a job application, a photo with a support request, a brief with a quote request.

The field checks what kind of file a visitor is uploading before it saves it. In versions up to 4.2.1, the check and the save read the submission differently, so a deliberately malformed submission could get a file past the check without it ever being inspected. The result is that someone who has never logged in to the site can place a PHP script in a public folder on the server and then run it.

Security researchers call this “unrestricted upload of file with dangerous type”, catalogued as CWE-434. In plain terms, the form’s attachment slot can be used as a door into the server.

The flaw was reported to Patchstack by Tin Pham (TF1T) of VietSunshine Cyber Security Services on 16 July 2026. Elementor fixed it in Pro 4.2.2 on 19 August 2026, and Patchstack published the advisory the same day.

Who is affected?

A WordPress site is exposed to CVE-2026-32475 when all three of these are true:

1. Elementor Pro is installed, at version 4.2.1 or earlier.
2. A page is published that contains an Elementor Pro Form widget.
3. That form has a File Upload field.

No unusual settings are needed. The field is vulnerable in its default state, and Patchstack notes the form does not even need the field marked as required.

The free Elementor Website Builder plugin, which has more than ten million active installations on wordpress.org, does not include the Forms module and is not affected. Elementor Pro is the paid product; BleepingComputer puts it at more than six million active installations. A great many of them use the form builder, because it is one of the main reasons people pay for Pro.

If your site uses Elementor and has a contact form, careers page or quote form with an attachment option, assume you are in scope until someone checks the version.

What can an attacker do?

Take over the website. That is not an exaggeration of the risk; it is the risk.

Once an attacker can run their own PHP on the server, they can read the WordPress configuration file, which holds the database password. From there they can create an administrator account, change any content, install more malicious code, read every form submission and customer record the site holds, and use the server to attack others or send spam. In practice attackers plant a web shell, a small script that gives them a permanent back door, so that they keep access even after the site is updated.

Three features of this vulnerability make it worse than most:

• No login needed. The attacker is an anonymous visitor. There is no password to guess and no account to compromise first.
• No user interaction. Nobody at your organisation has to click anything.
• The upload lands in a public folder. Form attachments are saved under wp-content/uploads/elementor/forms/, which is web-accessible by design, so the attacker can call their script directly.

The official score is 9.0 out of 10 on the CVSS 3.1 scale, rated Critical. The vector rates attack complexity as High, which is why it is 9.0 and not 9.8; some news coverage quotes 9.8, but 9.0 is the figure in the CVE record and in NVD. In the real world the difference did not matter: the attack was automated and running at scale within days.

Is it being exploited?

Yes. Wordfence, which runs a firewall on a large share of WordPress sites, reported that exploitation attempts began on 19 August 2026, the day Elementor released the fix, and that its firewall blocked more than 190,000 attempts between 19 and 23 August. By early September it put the total at close to 200,000. Attackers were uploading web shells to the forms upload folder and then running commands through them.

A public proof-of-concept exploit has since appeared on GitHub, which lowers the bar further.

As of the 8 October 2026 edition of the catalogue, CVE-2026-32475 is not listed in CISA’s Known Exploited Vulnerabilities list. That list lags, and it is a United States federal procurement tool rather than a measure of what is happening to Australian websites. Wordfence’s numbers are the better guide here.

What should you do now?

In this order:

1. Find out whether Elementor Pro is installed, and its version. In WordPress, go to Plugins. Look for “Elementor Pro”. The version number is on the row. Anything below 4.2.2 is vulnerable.
2. Update Elementor Pro. Update to the latest release, not just 4.2.2. On 9 October 2026 the latest Pro release is 4.3.1. If the update button is missing, the licence has probably lapsed on someone else’s account, which is its own problem and a common one on inherited sites.
3. Check the uploads folder. Look in wp-content/uploads/elementor/forms/ for any file ending in .php. That folder should only ever hold the documents and images your forms accept. A PHP file there is a strong sign the site has already been compromised.
4. If you find one, treat the site as breached. Updating the plugin will not remove it. Take the site offline or put it behind maintenance mode, restore from a backup taken before 19 August 2026 if you have one, change every password the site holds (WordPress admin accounts, the database, FTP or SSH, and any API keys in the configuration), and have someone qualified review the server for anything else left behind.
5. Record what you did and when. If this becomes an insurance claim, a Privacy Act notification question, or an awkward board paper, you will want dates.
6. Check whether you have forms with File Upload fields you don’t need. Fewer open doors is better regardless of this CVE.

If step one is already beyond what you can find out about your own website, that is the problem this blog exists to talk about. Skip to the bottom.

Why updating is not the whole fix

The update stops new attacks. It does nothing about the seven weeks between 19 August and today in which the site may have been attacked, nor about anything uploaded in that window. Elementor’s own changelog for 4.2.2 describes the fix as “Improved code security enforcement in Form widget”, with no mention of a CVE or a severity, so a site owner reading the update notes would have no reason to look harder.

There is a second half to this. A PHP script uploaded through a form runs as the web server user, which is exactly the low-privileged local foothold that kernel flaws like the one in USN-8903-1 turn into full control of the server. A patched site on an unpatched server has done half the job.

That is the pattern with most serious WordPress vulnerabilities. The fix arrives quietly, the attacks arrive the same day, and the gap between the two is filled by whoever is actually watching the site. For a lot of Australian businesses the honest answer to “who is watching?” is nobody: the host looks after the server, the agency that built the site has moved on, and the plugin updates belong to no one.

What this looks like with BLACKBX

BLACKBX scans every site it looks after daily against published security advisories, including the Patchstack and Wordfence databases that this CVE appears in. When a plugin on a client’s site matches a critical advisory, our developers patch it immediately; lower-severity items are done at the next service. After an update like this one, we check the uploads folder for anything that should not be there. Every step is dated and recorded in the client’s logbook, so the answer to “were we affected, and what did you do?” is a page, not a phone call.

On the Monitor plan, you get the same scan and the finding goes to your own developer with the version numbers and the advice above. On Maintenance and Full service, we do the work.

Timeline

Sources

• CVE-2026-32475 record, CVE Program (assigned by Patchstack)
• CVE-2026-32475 at NVD, National Vulnerability Database
• Critical unauthenticated file upload to RCE in Elementor Pro plugin, Patchstack, 19 August 2026
• Elementor Pro ≤ 4.2.1 vulnerability entry, Wordfence Intelligence
• Critical Elementor Pro flaw exploited to take over WordPress sites, BleepingComputer, 3 September 2026
• Elementor Pro changelog, Elementor
• Known Exploited Vulnerabilities Catalog, CISA, checked 9 October 2026

Facts checked on 9 October 2026 against Canonical’s notice and CVE pages, CISA, Red Hat, SUSE, Oracle Linux, Amazon Linux, Qualys, TuxCare and CloudLinux. Sources are listed at the end.

What is USN-8903-1?

USN-8903-1 is a security notice from Canonical, the company that makes Ubuntu. Ubuntu is a version of Linux, the operating system that a great many web servers run on. A USN, or Ubuntu Security Notice, is how Canonical announces that it has released fixes. This one, titled “Linux kernel vulnerabilities”, was published on 8 October 2026 and covers the kernel as packaged for Ubuntu 24.04 LTS and 22.04 LTS. LTS stands for long-term support: these are the releases most servers run.

The kernel is the core of the operating system. It sits between programs and the hardware, and it runs networking, files, memory and devices. Your website, its database and everything else on the server sit on top of it.

This notice is not one bug. Ubuntu’s notice index lists “CVE-2026-63949, CVE-2026-63957, CVE-2026-64014 + 229 others”, which makes 232 separate flaws. A CVE is the public reference number given to a single security flaw. Canonical’s summary is short: “Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system.” The fixes reach into many parts of the kernel, including Netfilter (the built-in firewall), IPv4 and IPv6 networking, the Ext4 file system, FUSE, SMB, Bluetooth, USB and graphics drivers, and memory management.

One of those 232 matters more than the rest: CVE-2026-53266. It is the reason our scanner marks this notice as being on CISA’s list of exploited vulnerabilities. That list names individual CVEs, not Ubuntu notices, so the notice itself has no entry of its own.

In plain terms, CVE-2026-53266 is a flaw in a feature called “ebtables SNAT”, part of the kernel’s bridge firewall. A bridge is a software connection that joins network interfaces together, and the bridge firewall filters traffic crossing it. Red Hat says the flaw can let a local attacker corrupt memory, crash the system or possibly gain higher privileges, meaning more control over the server than they should have. Sources describe the type of flaw differently. CISA calls it an “Out-of-Bounds Write”, where the kernel writes outside the memory it is meant to use. Red Hat lists it as CWE-825, “Expired Pointer Dereference”, where the kernel uses memory it should already have let go of. Either way, the result is the kernel’s memory being damaged.

Our scanner’s CVE list for USN-8903-1 includes CVE-2026-53266. The copy of Canonical’s page we could read was cut off before its list of CVEs ended, so we have not seen that line on Canonical’s page ourselves. Canonical’s own page for the CVE, last updated on 29 September 2026, still showed 22.04 and 24.04 as “Vulnerable, work in progress” at that point.

Who reported the flaws is not known, either for the notice or for CVE-2026-53266. CVE-2026-53266 was published on 25 June 2026.

Which versions are fixed, and which are not

For USN-8903-1 to apply to your website, all of these must be true:

1. Your website runs on a server using Ubuntu 24.04 LTS or Ubuntu 22.04 LTS.
2. That server uses one of the kernel packages the notice covers. On 24.04 these are linux, linux-aws, linux-aws-fips, linux-fips and linux-realtime, plus linux-aws-6.8 and linux-realtime-6.8. On 22.04, only the 6.8-based kernels are covered: linux-aws-6.8 and linux-realtime-6.8.
3. The kernel has not yet been updated to the fixed versions released on 8 October 2026.

The fixed versions we saw on Canonical’s page include:

• linux-image-6.8.0-146-fips: 6.8.0-146.146+fips1
• linux-image-kvm: 6.8.0-146.146
• linux-image-aws and linux-image-aws-6.8 on 22.04: 6.8.0-1066.69~22.04.1

Our scanner’s data lists these as well, which we could not see on Canonical’s page ourselves: 6.8.0-146.146 for the standard 24.04 linux kernel, 6.8.0-1066.69 for linux-aws, 6.8.0-1066.69+fips1 for linux-aws-fips, 6.8.1-1061.62 for linux-realtime, and 6.8.1-1061.62~22.04.1 for linux-realtime-6.8 on 22.04. The latest kernel version available today is not known.

What this notice does not cover:

• Azure, Google Cloud and IBM kernels. These have their own notices, published the same day: USN-8904-1 for Azure, USN-8905-1 for Google Cloud and USN-8906-1 for IBM. If your server is on one of those platforms, the relevant notice is that one, not this one.
• Ubuntu 26.04 LTS. For CVE-2026-53266, Canonical shows 26.04 as fixed in 7.0.0-31.31, which arrived in USN-8726-3 on 21 September 2026.
• The standard Ubuntu 22.04 kernel, version 5.15. It is not in this notice’s package list. The notice says nothing either way about whether it is affected, and we have not established whether it gets these fixes elsewhere. Do not read its absence as a clean bill of health. CloudLinux, a vendor that ships its own kernels, says CVE-2026-53266 is present in its 5.15 kernel for Ubuntu 22.04 but “out of reach by default”.
• Older releases, for CVE-2026-53266 specifically. Canonical lists Ubuntu 20.04 LTS as “Vulnerable”. It lists 18.04, 16.04 and 14.04 as “Not affected”.

Not every one of the 232 flaws affects both releases. Canonical lists CVE-2026-92502, for example, as “Not affected” on 22.04 but vulnerable on 24.04. How many servers run the affected kernels is not known.

If your site runs on an Ubuntu 22.04 or 24.04 server and nobody has updated its kernel since 8 October 2026, assume you are in scope until someone checks the version.

Why this matters for a website owner

The worst case is the one Canonical states in its own summary: an attacker could possibly use these flaws to compromise the system. The system here is the server your website runs on, not just the website.

Most website problems sit inside the website: a plugin, a theme, a form. A kernel flaw sits underneath all of that. If an attacker gains higher privileges on the server, the website, its database and anything else stored there are within their reach. Three things make CVE-2026-53266 worth acting on now:

• It is already being exploited. CISA, the United States cyber security agency, added it to its list of known exploited vulnerabilities on 18 September 2026. That is not a prediction. It is a record of attacks that have happened.
• Nobody agrees on whether a login is needed. Canonical and the Linux kernel CNA (the official body that issues CVEs for the kernel) say the attacker needs a low-privilege account on the server, with no user interaction needed. Red Hat also describes a “local attacker”. But SUSE and Amazon score it as reachable from the local network without any account, Red Hat’s and Oracle’s scores use a network attack route, and SecurityWeek says it can be triggered “with a crafted packet”.
• It sits under everything. The kernel runs the server’s networking, memory and files. A flaw at that level is not confined to one website or one user account.

There are real limits, and they are worth knowing. Red Hat says the flaw only matters if the server has specific bridge firewall rules configured. CloudLinux says an ordinary account can only reach it where “private network spaces are open”. Many web servers will not have that setup. Whether yours does is something to check, not something to assume.

On scoring: the notice as a whole has no overall score from Canonical. The “High” rating is from our scanner. For CVE-2026-53266 itself, CVSS (a 0 to 10 severity scale) scores vary by organisation:

• Canonical: 8.8, High, with Ubuntu priority “High”
• Linux kernel CNA: 8.8
• Red Hat: 7.5
• Oracle: 7.5
• SUSE: 6.8
• Amazon Linux: 5.3

The gap comes from different assumptions. The 8.8 scores assume an attacker with a low-privilege account on the server, and that the damage can spread beyond the part of the system first attacked. SUSE and Amazon assume an attacker on the same local network with no account, but rate the attack as harder to pull off; Amazon also rates the harm lower. We found no score from NVD, the US government’s vulnerability database. SecurityWeek and Security Affairs both report 8.8.

The other 231 flaws in the notice have not been assessed one by one here.

Which of the CVEs is being exploited?

CVE-2026-53266. CISA added it to its Known Exploited Vulnerabilities list, often called KEV, on 18 September 2026, “based on evidence of active exploitation”. KEV is CISA’s public list of flaws it knows attackers are using. US federal agencies had until 21 September 2026 to fix it, under CISA directive BOD 26-04.

On public exploit code, meaning attack tools anyone can download:

• Qualys says Red Hat’s advisories acknowledge active exploitation and report that public exploits are known.
• TuxCare says public exploit code exists for “two of the three” kernel CVEs added to KEV at that time, without saying which two.

What is not known: who is exploiting it, since when, and how widely. TuxCare says neither CISA nor Red Hat has published an attack chain, targets or telemetry, and that use by ransomware groups is listed as unknown.

One small inconsistency: CISA’s alert is titled “Two” and names CVE-2025-39964 and CVE-2026-53266, while the press reports three kernel flaws added that day. This does not change CVE-2026-53266’s status. Two other kernel flaws put on KEV in September 2026, CVE-2025-39682 and CVE-2025-39964, are not in this notice’s CVE list according to our scanner. We found none of the other 231 CVEs in USN-8903-1 on KEV.

For an Australian business, the US federal deadline does not apply. What the KEV listing does tell you is that this has moved from theory to practice. Ubuntu’s fix for 22.04 and 24.04 arrived 20 days after the KEV listing. For a website on one of those servers, the deadline that matters is today.

What should you do now?

In this order:

1. Find out what your server runs. You need three things: the Ubuntu release (22.04, 24.04 or something else), the kernel package, and the kernel version currently running. If you are on shared hosting, your host will know. If your website is on its own server or cloud account, ask whoever set it up or manages it. Ask them directly whether USN-8903-1 applies, or USN-8904-1, USN-8905-1 or USN-8906-1 if the server is on Azure, Google Cloud or IBM.
2. Update the kernel. Install the updated kernel packages for your Ubuntu release. Canonical’s notice has an “Update instructions” section for each package. Our scanner’s advice is to update the kernel package and reboot; we could not confirm that wording on Canonical’s page. Either way, ask whoever does the update to confirm the server is actually running the fixed version afterwards, not just that it was installed.
3. If the update cannot happen today, ask about the workaround. For CVE-2026-53266 only, Red Hat describes a temporary workaround involving the server’s ebtables SNAT bridge firewall rules. It is a job for whoever manages the server, and it covers one flaw, not the other 231.
4. Check for signs of compromise. No vendor or researcher has published indicators of compromise for this flaw, so there is no checklist to work from. Ask whoever manages the server whether anything unusual has been seen since late June.
5. If you think the server was compromised, treat it as a problem with the whole server, not just the website. No vendor has published specific steps beyond updating, and an update stops new attacks; it does not remove anything already there. Get whoever manages the server involved before changing anything.
6. Record what you did. Write down the date, the kernel version before and after, and who did it. If anything goes wrong later, that record is the first thing anyone will ask for.
7. Reduce exposure. If the server is on Ubuntu 20.04, Canonical lists it as vulnerable to CVE-2026-53266 and this notice does not cover it, so ask what the plan is for that server. If you are on the standard 22.04 kernel (5.15), ask how it is being kept up to date, because this notice does not answer that.

If step one is already beyond what you can find out about your own website, that is the problem this blog exists to talk about. Skip to the bottom.

Why updating is not the whole fix

CVE-2026-53266 was published on 25 June 2026. Oracle Linux shipped its first fixes on 14 July. CISA listed it as exploited on 18 September. Ubuntu 26.04 was fixed on 21 September. The fix for Ubuntu 22.04 and 24.04 in this notice arrived on 8 October 2026, 15 weeks after the flaw was published and 20 days after it was confirmed as exploited.

The update stops new attacks. It does nothing about those weeks in which the server may have been attacked, nor about anything an attacker changed or left behind in that window. And because no one has published signs of compromise for this flaw, there is no simple test that tells you the server is clean.

There is also the question of whether the update is really in place. A kernel update that has been downloaded but is not yet running leaves the server exactly where it was. Our scanner’s advice includes a reboot for that reason, and whoever does the work should confirm the running version afterwards.

Then there is the question of who is actually watching the site. The host looks after the server, the agency that built the site has moved on, and the plugin updates belong to no one. A kernel notice sits right on the line between those jobs. On shared hosting, the kernel is usually the host’s responsibility. On a website’s own cloud server, it belongs to whoever is looking after that server, and many owners do not know who that is until they need to ask.

That is the pattern with most serious server vulnerabilities. The fix arrives quietly, the attacks may already be under way, and the gap between the two is filled by whoever is actually watching.

What this looks like with BLACKBX

BLACKBX scans every site it looks after daily against published security advisories, including notices like USN-8903-1. When a client’s site matches a critical advisory, our developers patch it immediately; lower-severity items are done at the next service. Every update is dated and recorded in the client’s logbook, so there is always an answer to “when was this fixed, and to what version?”

On the Monitor plan, the finding goes to the client’s own developer with the version numbers and advice, so they can do the work. On Maintenance and Full service, BLACKBX does the work. All plans are monthly, with no minimum term.

Timeline

Sources

• USN-8903-1: Linux kernel vulnerabilities, Canonical, 8 October 2026
• Ubuntu Security Notices, Canonical, Accessed 9 October 2026
• USN-8905-1, Canonical, 8 October 2026
• USN-8906-1, Canonical, 8 October 2026
• CVE-2026-53266, Canonical, Last updated 29 September 2026
• CVE-2026-92502, Canonical, 18 September 2026
• CISA Adds Two Known Exploited Vulnerabilities to Catalog, CISA, 18 September 2026
• CVE-2026-53266, Red Hat
• CVE-2026-53266, SUSE
• CVE-2026-53266, Oracle Linux
• CVE-2026-53266, Amazon Linux (ALAS)
• Organizations Warned of 3 Exploited Linux Kernel Vulnerabilities, SecurityWeek, About 22 September 2026
• CISA Flags Three Linux Kernel Vulnerabilities Exploited in the Wild, The Hacker News, 19 September 2026
• U.S. CISA adds Linux Kernel flaws to its KEV catalog, Security Affairs, About 21 September 2026
• CISA adds Linux kernel flaws to exploited vulnerabilities catalog, SC World, 21 September 2026
• CISA BOD 26-04 Timelines for Three Linux Kernel CVEs, Qualys, 23 September 2026
• Three Old Linux Kernel Bugs Added to the CISA KEV List, TuxCare, About 3 October 2026
• Three KEV-listed Linux kernel CVEs: status and fixes for CloudLinux, CloudLinux, About 8 October 2026
• USN-8726-3 summary, LinuxSecurity, 21 September 2026

Facts checked on 13 October 2026 against WordPress.org’s release post and documentation, Patchstack, Pantheon, Jump.bg, MagicWP, Wordify and other coverage of the 7.1.3 release. Sources are listed at the end.

What is the WordPress pending-comment XSS flaw?

WordPress is the software that runs many small-business websites. This flaw is in WordPress itself, often called WordPress Core, not in a plugin or a theme. That matters: there is nothing to switch off or uninstall. The only fix is to update WordPress.

The flaw sits on the Comments administration page. That is the screen inside the WordPress dashboard where your staff read comments that visitors have left, then approve or reject them. Comments waiting for a decision are called “pending” comments.

It is a stored cross-site scripting flaw, usually shortened to stored XSS. Cross-site scripting means an outsider gets their own code to run inside someone else’s web browser while that person is using your site. “Stored” means the code is saved on your website and waits there for someone to open it.

In plain terms, a stranger can leave a comment carrying hidden code. Nobody has to approve it. It sits in your moderation queue, and when someone on your team who can see the Comments page clicks a link the comment has planted there, the code runs in their browser while they are logged in to your dashboard. Wordfence’s description, which our scanner carries but which we could not check against Wordfence’s own page, places the cause in how the dashboard handles links in its help tabs.

The flaw has no CVE number. A CVE is the public reference number most security flaws are given. WordPress did not publish CVE numbers or severity scores for any of the seven security fixes in 7.1.3, so this one is known by its description: the stored XSS on the Comments administration page, exploitable through pending comments, fixed in WordPress 7.1.3.

It was reported by Thomas Chauchefoin at Trail of Bits. One Japanese summary of WordPress’s announcement says the report was made in collaboration with OpenAI; the English copies of the announcement we could read do not mention OpenAI. The date it was reported to WordPress has not been published. The fix shipped in WordPress 7.1.3 on 6 October 2026.

One thing to keep separate. WordPress fixed a different comment-related XSS in 7.1.1, tracked as CVE-2026-93485. That is another flaw in different code, with a different reporter and a different fix. Some coverage blurs the two. This post is about the one fixed in 7.1.3.

Who is affected?

Your site is in scope if all of these are true:

1. It runs WordPress.
2. Its WordPress version is 7.1, 7.1.1 or 7.1.2.
3. Someone who can see the Comments page in the dashboard, usually an administrator or a moderator, opens it and clicks the planted link.

What is not affected:

• WordPress 7.1.3. That is the fixed release.
• WordPress 6.5 to 7.0.x. These versions are affected by six of the seven issues fixed in 7.1.3, but not by this pending-comments one.
• WordPress 4.7 to 6.4.x. Also not affected by this one.

Those “not affected” points come from a hosting company’s write-up and from Patchstack’s review as reported by a third party. We could not open WordPress’s or Wordfence’s own list of affected versions. Every source we found agrees on the affected range of 7.1 to 7.1.2.

If your site is on an older branch, you are clear of this flaw but not of the release. The other six fixes still apply to you, and sources disagree on how far back WordPress had shipped patches for older branches on release day. WordPress’s own announcement, as reported by others, says only the latest version is actively supported.

How many sites run 7.1 to 7.1.2 has not been published.

If your site uses WordPress and has been kept reasonably up to date since 7.1 came out, assume you are in scope until someone checks the version.

What can an attacker do?

Run their code inside the dashboard, in the browser of the person who moderates your comments, while that person is logged in. Whatever that person is allowed to do on your site, code running in their browser can try to do. If they are an administrator, that is everything.

That is not a theoretical stretch. In a separate campaign this month, which used plugin flaws and not this one, Patchstack described attackers using stored XSS to plant an administrator account that hides itself. Patchstack also noted that any stored XSS that shows code to an administrator could deliver the same payload. This flaw is that kind of XSS.

What makes it worse:

• No login is needed to start it. Any visitor who can leave a comment can plant the code. Patchstack and The Repository both describe it as unauthenticated.
• The comment never has to be approved. According to Wordfence’s text in our scanner, and the way RS Web Solutions describes the trigger, the comment only needs to be sitting in the moderation queue.
• It lands in front of the most powerful people on the site. The Comments page is opened by administrators and moderators, the accounts with the most control.

What limits it: someone has to click. Patchstack is clear that a moderator must interact for the code to run. That is a real barrier, but checking pending comments is a routine job, and routine jobs get done on autopilot.

On severity, WordPress gave no score. Wordfence scores it CVSS 7.2, which is High. CVSS is the common 0 to 10 scale used to rate how serious a flaw is. That figure reaches us through our scanner’s feed; we could not open the Wordfence advisory to confirm the score or how it was worked out. There is no score from NVD, the United States government’s vulnerability database, because there is no CVE for it to score.

You may see other numbers in the press. SecurityOnline gives CVSS 7.2 for CVE-2026-93485, the earlier 7.1.1 flaw, and Patchstack and others score that one 7.1. Neither number belongs to the flaw in this post.

Is it being exploited?

No attacks have been reported. WordPress’s announcement does not mention any. SecurityOnline, as reported by Witscode, says there is no confirmed exploitation and no public proof of concept, meaning no published working example of the attack. Cybersecurity News reports that WordPress’s documentation gives no confirmed exploitation details. We found no source that says otherwise as of 13 October 2026.

There is an active XSS campaign against WordPress sites, which is why this is worth taking seriously. Patchstack first saw it on 4 October 2026. It uses flaws in two plugins, WPC Product Bundles for WooCommerce (CVE-2026-93836) and Ninja Forms (CVE-2026-94504), not this WordPress Core flaw. No source we found links this flaw to that campaign. The point is only that people are already running working attacks that turn stored XSS into control of a WordPress site.

CISA, the United States cybersecurity agency, keeps a Known Exploited Vulnerabilities catalogue, a list of flaws it has confirmed are being used in real attacks. A flaw without a CVE cannot be listed there. Our scanner reports it is not on the list; we did not check the catalogue directly.

Some hosts are already shielding customers. Pantheon says it has deployed platform-wide protection against outside abuse of this XSS, and it still tells customers to update.

For an Australian site, the practical reading is this. Nobody has reported attacks, the fix is a week old, and a working method for turning XSS into a hidden administrator account is already in use through other doors. Where your business is located does not change any of that.

What should you do now?

In this order:

1. Find out your WordPress version. Log in to the dashboard and go to Dashboard → Updates. If it shows 7.1, 7.1.1 or 7.1.2, you are in scope. If you cannot log in, or do not know who can, ask whoever manages the site.
2. Update to WordPress 7.1.3. On the same screen, click “Update Now”, or download 7.1.3 from WordPress.org. Sites that support automatic background updates will start updating on their own, but check the version rather than assume it happened. Sites that cannot write their own files need a manual update, usually by a developer.
3. Until the update is done, leave pending comments alone. Ask anyone who moderates comments not to open the Comments page or click links in pending comments until the site shows 7.1.3.
4. Check whether anything has already happened. WordPress publishes only a one-line description of this flaw, and no signs of compromise have been published. If anyone on your team clicked a link in a pending comment while the site was on 7.1 to 7.1.2, or if anything in the dashboard looks unfamiliar, have a developer review the site. Patchstack’s write-up of the separate plugin campaign describes an attacker account built to hide itself, which is why this is a job for someone who knows where to look, not a quick glance at the Users screen.
5. If you find signs of compromise, get help before carrying on. Neither WordPress nor the researchers have published clean-up steps for this flaw. Updating alone does not remove anything that was added before the update. A developer needs to work out what changed and put it right.
6. Record what you did. Write down the version you found, the version you updated to, the date, and who did it. If anything comes up later, that record is the first thing anyone will ask for.
7. Reduce your exposure. Limit who can moderate comments to the people who need to. Ask your host whether it shields sites from known flaws, as Pantheon has for this one. If your site is on an older branch, it is not affected by this flaw but still needs the other 7.1.3 fixes.

If step one is already beyond what you can find out about your own website, that is the problem this blog exists to talk about. Skip to the bottom.

Why updating is not the whole fix

The update closes the door. It does not tell you whether anyone walked through it.

This flaw has been present since WordPress 7.1. Two later updates, 7.1.1 on 17 September 2026 and 7.1.2 on 22 September 2026, did not fix it. A site that did everything right and installed both was still exposed. The fix arrived on 6 October 2026, a week before this post. Any site still on 7.1.2 today is still open.

If someone on your team clicked a planted link before the update, whatever the code did in that moment stays done. An account created, a setting changed, a file added: the update does not reverse any of it. WordPress has also not published guidance on whether comments planted before the update need to be cleared out of the queue.

So the question is not only “is it updated?” but “who would have noticed?” And on most small-business sites, the honest answer is that nobody is in a position to notice. The host looks after the server: the machine, the network, the backups. The agency that built the site has moved on to other clients. The WordPress and plugin updates belong to no one. They sit in a notification on a dashboard that the owner rarely opens, waiting for someone to decide they are their job.

That is the pattern with most serious WordPress vulnerabilities. The fix arrives quietly, and the gap between the fix and the update is filled by whoever is actually watching the site.

What this looks like with BLACKBX

BLACKBX scans every site it looks after daily against published security advisories. When a client’s site matches a critical advisory, our developers patch it immediately. Lower-severity items are done at the next service. Either way, every update is dated and recorded in the client’s logbook, so there is always an answer to “what version were we on, and when did that change?”

On the Monitor plan, the finding goes to the client’s own developer with the version numbers and our advice, so the people who know the site can act on it. On Maintenance and Full service, BLACKBX does the work. All plans are monthly, with no minimum term.

Timeline

Sources

• WordPress 7.1.3 Maintenance and Security Release, WordPress.org (Jake Spurlock), 6 October 2026
• Version 7.1.3, WordPress.org documentation, 6 October 2026
• Copy of the WordPress.org blog post with the reporter list, Four Head Realtors, about 7 October 2026
• AMPLIFY: WordPress 7.1.3 Maintenance and Security Release (issue #1651), WordPress/marketing on GitHub, 6 October 2026
• WordPress 7.1.3 Security Release, Patchstack, 6 October 2026
• Four ways back in: the WordPress XSS campaign that hides its own admin account, Patchstack, 6 October 2026
• WordPress 7.1.3 Security Release now available, Pantheon, 6 October 2026
• WordPress 7.1.3 Fixes SQL Injection, Stored XSS Flaws, Cyber Kendra, about 7 October 2026
• Critical WordPress Vulnerabilities Enable XSS, SQL Injection and Data Disclosure Attacks, Cybersecurity News, 7 October 2026
• WordPress 7.1.3 Patches Seven Vulnerabilities as Bug Bounty Payouts Top $90,000 in 90 Days, The Repository, about 7 October 2026
• WordPress 7.1.3 Maintenance and Security Release, ShapedPlugin, 7 October 2026
• WordPress 7.1.3 Update Fixes SQL Injection and XSS Threats, RS Web Solutions, about 9 October 2026
• WordPress 7.1.3 Fixes a Stored XSS in the Comments Screen, Private DevOps, 8 October 2026
• WordPress 7.1.3 Security Release: 7 Fixes Explained, MagicWP, about 7 October 2026
• WordPress 7.1.3 Security Release: SQL Injection and XSS Fixes, Witscode, about 7 October 2026
• WordPress 7.1.3: seven security fixes…, Wordify, about 7 October 2026
• WordPress 7.1.2: one critical fix…, Wordify, about 24 September 2026
• WordPress 7.1.3: Seven Security Fixes, Jump.bg, about 8 October 2026
• WordPress 7.1.3 security update fixes seven Core issues, Webtaculos, about 6 October 2026
• WordPress 7.1.3: What Changed…, Webless, 6 October 2026
• WordPress releases 7.1.3, includes 7 security fixes, note.com (リサーチおじさん), about 10 October 2026
• WordPress Stored XSS Details and PoC Publicly Disclosed (about CVE-2026-93485, a different flaw), SecurityOnline, about 24 September 2026
• WordPress 7.1.1 Fixes a Comment-Form XSS (about CVE-2026-93485, a different flaw), webhosting.today, 22 September 2026

Facts checked on 14 October 2026 against Ubuntu’s notices USN-8917-1, USN-8918-1, USN-8911-1 and USN-8903-1, CISA, Qualys, The Hacker News, Security Affairs and UbuntuUpdates.org. Sources are listed at the end.

What is USN-8917-1?

USN-8917-1 is a security notice from Canonical, the company behind Ubuntu, published on 13 October 2026. A USN (Ubuntu Security Notice) is Ubuntu’s announcement of one update. For the kernel, one update usually fixes many separate vulnerabilities at once. This one covers the Linux kernel on Ubuntu 24.04 LTS, the long-term support release code-named “noble”.

The kernel is the core of the operating system. It is the layer between the server’s hardware and every program on it, including the web server, PHP and the database that together run your website. If your website lives on an Ubuntu 24.04 server, this kernel is underneath it.

Ubuntu’s own summary is short: “Several security issues were fixed in the Linux kernel.” It adds: “An attacker could possibly use these to compromise the system.”

The advisory feed we scan against lists about 1,050 separate CVEs in this notice. A CVE is the public ID number given to one vulnerability. We have not counted them against Ubuntu’s page ourselves, so treat that number as approximate. The fixes reach across a long list of kernel areas, including Bluetooth, graphics (GPU), Hyper-V, InfiniBand, input devices, SCSI and SPI drivers, the TPM driver, the hardware crypto drivers, the GPIO subsystem, RBD and DRBD block devices, the Amazon Nitro Secure Module driver and several others.

The only flaw Ubuntu describes on its own is CVE-2023-20585. Some AMD processors did not properly check memory permissions in one situation. Someone with control of the hypervisor (the software layer that runs virtual machines, normally operated by the hosting provider) could possibly use this to tamper with protected virtual-machine memory.

In plain terms, this is a large kernel update that closes a great many holes in the foundation your website stands on, and it does nothing until the server is restarted.

There is no single reporter, because the notice bundles many independent issues. One CVE in the list is worth naming. CVE-2026-68121 was called “PPPoEject” by The Hacker News on 19 September 2026, which reported it as one of four local privilege-escalation flaws disclosed by researcher Asim Manizada. A privilege escalation lets someone who already has a small foothold on a server give themselves full control of it. Its place in this notice comes from our advisory feed’s list; we have not confirmed it on Ubuntu’s own page for that CVE.

Who is affected?

Your server is in scope if all of these are true:

1. Your website runs on a server, or a virtual server, using Ubuntu 24.04 LTS.
2. That server uses one of the kernels this notice covers: the standard generic kernel, lowlatency, fips, the cloud kernels for AWS, Google Cloud (gcp, gke and gkeop), IBM and Oracle, or the real-time kernel.
3. The kernel actually running on it is older than the fixed version for its flavour, listed in the next section.

The third point matters. A server can have the new kernel installed and still be running the old one, because the change only takes effect after a reboot.

What this notice does not cover:

• The Azure kernel. Servers on Microsoft Azure’s kernel are covered by a separate notice, USN-8918-1, which lists USN-8917-1 as related.
• OEM kernels. These are covered by USN-8911-1, published on 9 October 2026.
• Ubuntu 22.04. Servers on 22.04 running 6.8 kernels received fixes in other notices, such as USN-8903-1 on 8 October 2026. We explained that one in our post on USN-8903-1.
• Other Ubuntu releases. Releases such as 20.04 are not listed on USN-8917-1. Whether they are affected by the same flaws was not established.

How many servers run Ubuntu 24.04 with these kernels is not known.

If you are on shared or managed hosting, the hosting company controls the kernel. You cannot update it yourself, but you can ask whether this update has been applied and the server rebooted.

If your site runs on an Ubuntu 24.04 server and nobody has confirmed a kernel update and a reboot since 13 October 2026, assume you are in scope until someone checks the version.

Which versions are fixed, and which are not

All of these fixes were published on 13 October 2026 for Ubuntu 24.04 LTS. Any kernel older than the version shown for its flavour is not fixed.

• generic and generic-64k: 6.8.0-147.147
• fips: 6.8.0-147.147+fips1
• lowlatency and lowlatency-64k: 6.8.0-147.147.1
• aws and aws-64k: 6.8.0-1067.70
• aws-fips: 6.8.0-1067.70+fips1
• gcp and gcp-64k: 6.8.0-1071.79
• gcp-fips: 6.8.0-1071.79+fips1
• gke and gke-64k: 6.8.0-1066.74
• gkeop: 6.8.0-1052.56
• ibm: 6.8.0-1067.68
• oracle and oracle-64k: 6.8.0-1064.67
• realtime: 6.8.1-1062.63, available only with Ubuntu Pro, Canonical’s paid support subscription

The FIPS packages are labelled by Ubuntu as “FIPS Updates FIPS-140 certified package”. FIPS kernels are used where a certified cryptography setup is required, usually by government and regulated organisations.

Whether a newer kernel has been released since 13 October 2026 is not known. If your server shows a higher number than the one above for its flavour, it already includes these fixes.

One small uncertainty. A third-party package tracker, UbuntuUpdates.org, appeared to show 6.8.0-147.147 in Ubuntu’s update channel on a page dated before the notice. That may mean the package was available a little earlier than 13 October. We have not verified it, and it does not change what you need to do.

Why this matters for a website owner

If one of these flaws is used against your server, the attacker could take control of the machine your website runs on, and everything on it: the site, the database, customer details and email that passes through it. Ubuntu’s words are that an attacker “could possibly use these to compromise the system”.

Three things shape how worried to be:

• The flaws we know about need a foothold first. The two flaws described individually are local. CVE-2023-20585 needs someone who already controls the hypervisor, which is normally the hosting provider’s level. CVE-2026-68121 is a local privilege escalation, which means the attacker must already be able to run code on the server. For the other thousand or so CVEs, Ubuntu does not say whether a login or local access is needed.
• A website can be the foothold. A flaw in a website plugin or theme that lets someone run code on the server gives them exactly the local access these kernel flaws need. On its own, a hacked website is bad. Combined with an unpatched kernel, it can become a lost server.
• Installing is not the same as fixing. The kernel update is only in effect after the server reboots. Servers that install updates automatically but are never restarted keep running the old, flawed kernel.

There is no single severity score for this notice. Severity scores for individual flaws use CVSS (the Common Vulnerability Scoring System), which rates a flaw from 0 to 10. Ubuntu does not put one CVSS score on a bundled kernel notice, and each CVE inside it has its own score, which we were not able to retrieve. The advisory feed our daily scan reads rates USN-8917-1 as HIGH. We could not establish who assigned that rating, so read it as a sign of priority, not as an official score.

Is it being exploited?

Not known. We found no report of in-the-wild exploitation for USN-8917-1 or for any CVE we could confirm is in it. We also found no press coverage of this notice.

The question of the CISA KEV list needs care. CISA is the US government’s cyber security agency, and its Known Exploited Vulnerabilities (KEV) catalogue lists flaws it has evidence are being used in real attacks. Our advisory feed marks this notice as containing a KEV-listed flaw. We tried to confirm that and could not:

• CISA added Linux kernel flaw CVE-2026-31431 to KEV on 1 May 2026.
• CISA added Linux kernel flaws CVE-2025-39682, CVE-2025-39964 and CVE-2026-53266 to KEV on 18 September 2026, as reported by Qualys and Security Affairs.
• None of those four is in our feed’s list of CVEs for USN-8917-1. We checked them by hand.

We could not compare all of the roughly 1,050 CVEs against the full catalogue, so we cannot say whether this notice contains a KEV-listed flaw or not. The honest answer is that it is unresolved.

On proof-of-concept code, meaning published code that demonstrates a flaw, we found nothing. CVE-2026-68121 (“PPPoEject”) has been publicly disclosed, but whether exploit code was released was not established.

What this means for an Australian website: attackers do not care which country a server is in. The four KEV entries above show that Linux kernel flaws were being used in real attacks this year. With a HIGH rating and a disclosed privilege-escalation flaw in the list, there is no good reason to wait for confirmation before updating.

What should you do now?

In this order:

1. Find out which kernel your server is running. Whoever manages the server can check this. On Ubuntu, the command uname -r shows the running kernel, for example 6.8.0-147-generic. Compare it with the list above. If you are on managed or shared hosting, ask the hosting company whether USN-8917-1 has been applied and whether the server has been rebooted since.
2. Install the update. A standard system update brings in the fixed packages. Ubuntu’s standard kernel packages, such as linux-generic and linux-virtual, pull in the new kernel automatically unless someone has manually uninstalled them.
3. Reboot the server. Ubuntu says: “After a standard system update you need to reboot your computer to make all the necessary changes.” Plan a short outage for your website while this happens, and check the site comes back afterwards.
4. Rebuild any third-party kernel modules. These are add-on drivers that do not come from Ubuntu. Ubuntu says an “unavoidable ABI change” gives the kernel a new version number, which “requires you to recompile and reinstall all third party kernel modules you might have installed.” Most website servers have none, but whoever manages yours should confirm.
5. Check for compromise. Ubuntu has published no signs of compromise for this notice. If the server or website has shown anything nobody can explain in recent weeks, have it reviewed before assuming the update settled it.
6. If you find evidence of compromise, treat it as an incident. Updating closes the holes; it does not remove anyone already inside. Have a qualified person decide whether the server can be cleaned or needs to be rebuilt.
7. Record what you did. Write down the date, the kernel version before and after, and when the server was rebooted. The next time a notice like this comes out, you will know where you started.
8. Reduce your exposure. Because the known flaws need a foothold, keep the website itself up to date and remove plugins, themes and accounts nobody uses. Fewer ways in means fewer chances for a local flaw to matter.

If step one is already beyond what you can find out about your own website, that is the problem this blog exists to talk about. Skip to the bottom.

Why updating is not the whole fix

The update stops these flaws being used from the moment the server reboots. It does nothing about the time before that.

CVE-2026-68121 was publicly disclosed by 19 September 2026, more than three weeks before this notice was published on 13 October. Every day between disclosure and reboot is a day the server was running a kernel with a known hole in it. Every day after 13 October that the server goes without a reboot adds to that window.

The update also undoes nothing. If someone gained access to the server before it was patched, they keep whatever they set up. A new kernel does not remove a hidden account, a planted file or a stolen password. Ubuntu has not published guidance on checking for these, so it falls to whoever looks after the server to decide whether a check is needed.

Then there is the reboot itself. Kernel updates are easy to install and easy to forget, because nothing visible changes until someone restarts the machine. Plenty of servers have the fix sitting on disk and the old kernel still running.

That raises the question of who is actually watching the site. On managed hosting, the host looks after the server, and the kernel is theirs to update. The agency that built the website has usually moved on to the next project. The plugin updates and the website software, which are the foothold these kernel flaws need, belong to no one. And if your site runs on a server someone set up years ago, the reboot is someone’s job, but often nobody has been told it is theirs.

What this looks like with BLACKBX

BLACKBX scans every site it looks after daily against published security advisories, including Ubuntu’s security notices. When a client’s site matches a critical advisory, our developers patch it immediately. Lower-severity items are done at the next service. Every update is dated and recorded in the client’s logbook, so there is always an answer to “which kernel are we on, and when did it change?”

On the Monitor plan, the finding goes to your own developer with the version numbers and our advice, so they know exactly what to do. On Maintenance and Full service, BLACKBX does the work. All plans are monthly, with no minimum term.

Timeline

Sources

• USN-8917-1: Linux kernel vulnerabilities, Canonical / Ubuntu, 13 October 2026
• USN-8918-1: Linux kernel (Azure) vulnerabilities, Canonical / Ubuntu
• USN-8911-1: Linux kernel (OEM) vulnerabilities, Canonical / Ubuntu, 9 October 2026
• USN-8903-1: Linux kernel vulnerabilities, Canonical / Ubuntu, 8 October 2026
• CISA Adds One Known Exploited Vulnerability to Catalog, CISA, 1 May 2026
• CISA BOD 26-04 Timelines for Three Linux Kernel CVEs, Qualys, 23 September 2026
• CISA Flags Three Linux Kernel Vulnerabilities Exploited in the Wild, The Hacker News, 19 September 2026
• U.S. CISA adds Linux Kernel flaws to its Known Exploited Vulnerabilities catalog, Security Affairs
• Package “linux-tools-common” (noble 24.04), UbuntuUpdates.org

Facts checked on 21 October 2026 against copies of the CVE record at Vulners, OffSeq Radar, Strix and threatint, MariaDB’s release notes, change lists and Enterprise Server security page, Heart Internet, CVE Brief and TheHackerWire. Sources are listed at the end.

What is CVE-2026-85746?

MariaDB Server is database software. The official description calls it “a community developed fork of MySQL server”, which means it began as a copy of another well-known database and has been developed separately since. A database is the part of a system that stores information in an organised way so that software can look it up again later.

The flaw sits in a feature called ST_AsText. MariaDB can store map-style shapes, known as GIS data (geographic information system data: points, lines and areas). ST_AsText takes a stored shape and turns it into text. Shapes can be put into groups, and groups can sit inside other groups. When a group is nested very deeply inside other groups, ST_AsText goes wrong.

In plain terms, the database writes data past the end of the space it set aside for its answer. As it builds the text piece by piece, it does not keep track of how much room it has already used, and it does not reserve enough. The official classification is CWE-787, “Out-of-bounds Write”. CWE is a standard catalogue of software weakness types, and an out-of-bounds write means data spills into memory that belongs to something else.

The official title is “MariaDB: Out-of-bound buffer write on in ST_AsText of nested GeometryCollections”. MariaDB tracks it internally as bug MDEV-40329. Its bug tracker rates the issue “Blocker”, its highest priority, and lists it as closed. GitHub issued the CVE number, which was reserved on 4 September 2026 and published on 16 October 2026.

Who reported the flaw, and when, has not been published in any source we could check. The earliest date on record is the fix itself, written on 9 July 2026.

Do not confuse it with CVE-2026-85745 (MDEV-40328), a related bug in a different function called ST_Area. Two other MariaDB flaws rated 9.9, CVE-2026-85748 and CVE-2026-92262, were also published the same week. This post covers CVE-2026-85746 only.

Which versions are affected, and which are fixed?

For your site to be in scope, all of these must be true:

1. Your website, or something it relies on, stores its data in MariaDB Server.
2. That MariaDB is a version in one of these ranges:
   • 10.6.1 up to but not including 10.6.28
   • 10.11.1 up to but not including 10.11.19
   • 11.4.1 up to but not including 11.4.13
   • 11.8.1 up to but not including 11.8.9
   • 12.3.1 up to but not including 12.3.3
   • 13.0.1 (the only affected release in the 13.0 series)
3. Someone who has a database account, even a low-level one, could misuse it.

The fixed versions, with the dates in MariaDB’s own documentation:

• 10.6 series: 10.6.28, released 13 August 2026
• 10.11 series: 10.11.19, released 24 August 2026
• 11.4 series: 11.4.13, released 24 August 2026
• 11.8 series: 11.8.9, released 24 August 2026
• 12.3 series: 12.3.3, released 24 August 2026
• 13.0 series: 13.0.2, released 15 September 2026

MariaDB Enterprise Server, the paid edition, is also covered. Its fixes are 10.6.28-24, 11.4.13-10 and 11.8.9-6, all released on 7 September 2026.

One point of confusion: the written description says “From 10.6.1 until 10.6.28”, which one tracking site has read as including 10.6.28. The official version list makes clear that each fix version is not affected.

Another: a press source, Heart Internet, says the fixes appear to be releases that shipped on 13 October, but it says it could confirm its dates from only one source. We have used MariaDB’s own dates.

What is not affected is less clear than it should be. No source says outright which versions are safe. Versions older than 10.6.1, and the series 11.0 to 11.3, 11.5 to 11.7 and 12.0 to 12.2, are simply not on the affected list. Whether that is because they are unaffected or because they are no longer supported is not known. If your database runs one of those, do not treat its absence from the list as a clean bill of health.

The newest stable release today is 13.0.2, labelled “Latest” on GitHub. Test versions 13.1.1 (a release candidate) and 13.2.0 (a preview) also exist; they are not meant for a live website. Whether anything newer came out after mid-September is not known. Whether Linux distributions such as Ubuntu and Debian have released their own fixed packages is also not known, and neither is how many servers run the affected versions.

If your site uses a MariaDB database and nobody has confirmed its version since August, assume you are in scope until someone checks the version.

Why this matters for a website owner

Someone with a basic database login can corrupt the memory of the database server. The public code reported by one source crashes the server outright. The official description adds that an attacker could “potentially achieve code execution when combined with another vulnerability”: in plain terms, running their own code on the server would need a second flaw as well.

If your website depends on that database, a crashed database means a website that cannot show its pages, take its orders or log anyone in. A database that has had its memory corrupted is not one you can fully trust until someone has looked at it.

Three things shape how serious this is:

• A login is needed, but only a low-level one. Heart Internet describes these flaws as needing “a low-privileged database account rather than an administrator”. Any account that can send a shape to the database may be enough.
• No interaction is needed. Nobody on your side has to click a link or open a file.
• It can be reached over a network. The score treats it as attackable across a network and easy to carry out. Whether it can be reached through a website’s public pages, or only by someone connecting to the database directly, has not been published.

The score is CVSS 3.1 9.9 out of 10, rated Critical. CVSS is the standard scale used to rate how severe a vulnerability is. GitHub assigned the score as the issuer of the CVE number, and MariaDB lists the same 9.9 on its Enterprise Server security page. In plain terms, the score says: network reach, easy to do, a low-level login, no help from a user, and damage that can reach beyond the database itself with serious effects on data and service. The score assumes the worst realistic case, including the code execution that needs a second flaw.

NVD, the United States government’s vulnerability database, has not finished its analysis and has no score of its own yet. CISA, the US cyber security agency, has an entry for this CVE in its added-analysis programme, but its contents are not known. One tracking site labels the flaw “OS Command Injection”. That does not match the official type, which is an out-of-bounds write.

Is it being exploited?

Not as far as anyone has confirmed. Heart Internet says it “found no confirmed attacks”. TheHackerWire lists “No Known Campaign” for ransomware. Nobody has published who might be attacking, since when, or how many servers.

The sources disagree on whether attack code is public. Heart Internet says public code appeared on 18 October that “demonstrates a server crash”, and warns that “attackers may follow quickly”. TheHackerWire says “No Public PoC Detected”, though the date of its page is unclear. A PoC, or proof of concept, is code that shows a flaw can be triggered. We cannot tell you which report is right.

The flaw has an EPSS score of 0.00627 according to Vulners. EPSS is a statistical estimate of how likely a vulnerability is to be exploited, on a scale from 0 to 1.

It is not on CISA’s Known Exploited Vulnerabilities (KEV) catalogue, the US government list of flaws seen in real attacks, according to two sites that track it. We could not confirm that against CISA’s own catalogue today.

For an Australian site, the KEV list is a useful signal but not a safety certificate. It records attacks that have been seen, and it is maintained in the United States. A database that can be reached over a network can be reached from anywhere. If crash code is public, the realistic near-term risk is a site knocked offline, even if nothing more serious follows.

What should you do now?

In this order:

1. Find out the version. Ask your host, your developer or whoever manages the server two questions: does my website use MariaDB, and which exact version? None of the sources we checked give owner-level instructions for this, so the person who runs the server is the right one to ask.
2. Update. Move to the fixed version in your series: 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3 or 13.0.2. For Enterprise Server, that is 10.6.28-24, 11.4.13-10 or 11.8.9-6. If your database runs a series that is not on either list, ask about moving to one that has received this fix. No workaround, such as switching the feature off, has been published, so the update is the fix.
3. Check for trouble. Neither MariaDB nor any researcher has published signs of compromise. The only related fact is that the reported public code crashes the server. If your database has crashed or restarted without explanation since mid-October, tell whoever runs it.
4. If something looks wrong, treat it as an incident rather than a glitch. Have a qualified person investigate before anyone assumes the server is clean, and keep a copy of anything they find. MariaDB has not published specific recovery steps.
5. Record what you did: the version before, the version after, the date and who did it. If anything goes wrong later, this is the first thing anyone will ask for.
6. Reduce exposure. The attack needs a database account. Ask for a list of who and what has a login to your database, and have any account that is no longer needed removed. Ask, too, whether the database can be reached from the open internet, and whether it needs to be.

If step one is already beyond what you can find out about your own website, that is the problem this blog exists to talk about. Skip to the bottom.

Why updating is not the whole fix

The fix for the 10.6 series has been out since 13 August 2026, and for most other series since 24 August. The CVE was not published until 16 October, and crash code was reported two days later. Any server still on an affected version today has been exposed for every one of those days, and has been exposed in public since 16 October.

The update stops the flaw from being triggered again. It does nothing about any crash or memory corruption that may already have happened, and it does nothing about the database accounts that make the attack possible. A low-level login that was misused before the update still works after it, until someone removes it or changes its password.

There is also the question of the second flaw. The worst case here needs this bug and another one together. Updating MariaDB closes this half. Whether the rest of the server is up to date is a separate question that the update does not answer.

Then there is the question nobody likes to ask: who is actually watching the site? The host looks after the server, but the database version may sit in a grey area depending on how the hosting is set up. The agency that built the site has moved on to other projects. The plugin updates, the database updates and the security advisories belong to no one in particular, so nobody reads them.

That is the pattern with most serious vulnerabilities. The fix arrives quietly, the public notice arrives weeks later, and the gap between the two is filled by whoever is actually watching the site.

What this looks like with BLACKBX

BLACKBX scans every site it looks after daily against published security advisories. When a client’s site matches a critical advisory like CVE-2026-85746, our developers patch it immediately; lower-severity items are done at the next service. Every update is dated and recorded in the client’s logbook, so the question “which version were we on, and when did it change?” always has an answer.

On the Monitor plan, the finding goes to the client’s own developer with the version numbers and our advice, so they can act on it. On Maintenance and Full service, BLACKBX does the work. All plans are monthly, with no minimum term.

Timeline

Sources

• CVE-2026-85746 (copy of the official CVE record), Vulners, 17 October 2026
• CVE-2026-85746, Vulners, 18 October 2026
• CVE-2026-85746 (copy of the NVD entry), Vulners, 18 October 2026
• CVE-2026-85746: CWE-787 Out-of-bounds Write in MariaDB server, OffSeq Radar, 18 October 2026
• CVE-2026-85746, Strix, 18 October 2026
• CVE-2026-85746, threatint
• CVE-2026-85746, TheHackerWire
• CVE Brief, 17 October 2026, CVE Brief, 17 October 2026
• Weekly Cybersecurity Summary: 13–19 October 2026, Heart Internet, 20 October 2026
• Security Vulnerabilities (CVE) Fixed in MariaDB Enterprise Server, MariaDB, 14 October 2026
• Security Vulnerabilities (CVE) Fixed in MariaDB Community Server, MariaDB
• MariaDB 10.6.28 release notes, MariaDB, 13 August 2026
• MariaDB 10.11.19 release notes, MariaDB, 24 August 2026
• MariaDB 11.4.13 release notes, MariaDB, 24 August 2026
• MariaDB 11.8.9 release notes, MariaDB, 24 August 2026
• MariaDB 12.3.3 release notes, MariaDB, 24 August 2026
• MariaDB 13.0.2 release notes, MariaDB, 15 September 2026
• MariaDB 10.6.28 change list, MariaDB
• MariaDB 12.3.2 change list, MariaDB
• MariaDB 12.3.3 change list, MariaDB
• MariaDB 13.0.2 change list, MariaDB
• Release Notes – MariaDB 13.0 Series, MariaDB
• All Releases, MariaDB
• MariaDB 10.6.0 release notes, MariaDB
• MariaDB 11.4.11 release notes, MariaDB
• MariaDB Community Server Q3 2026 maintenance releases, MariaDB blog, 26 August 2026
• Releases, MariaDB/server, GitHub
• MDEV-40328, MariaDB bug tracker
• CVE-2026-85745, VulDB, 18 October 2026

Updated 22 October 2026, after PHP's release. Facts checked against PHP's security advisory, Ubuntu, CloudLinux, watchTowr and Sansec. Sources are listed at the end.

What are CVE-2026-109618 and CVE-2026-109619?

PHP is the programming language behind most of the web. WordPress, Silverstripe, Drupal, Magento and Joomla are all written in it, so if your website has a content management system, it almost certainly runs on PHP.

On 21 October 2026 PHP fixed two critical flaws in PHP itself. PHP describes them as remote code execution "via OOM corruption" (CVE-2026-109618) and "via stale global state" (CVE-2026-109619). Both are rated 9.2 out of 10.

Remote code execution means someone on the internet can make your web server run their own instructions. That is the most serious kind of flaw a website can have, because it gives the attacker the same control over the server that your website has.

Sansec explains the cause: when PHP runs out of memory in the middle of handling a request, it can go on using memory it has already freed. A specially crafted form submission, of the kind used for file uploads, is enough to trigger it, and the faulty code dates back to PHP 5.4, released in 2012.

Why this one is different

Most website security problems sit in a plugin, a theme or the content management system. Those can often be patched or switched off on their own.

These two flaws sit underneath all of that, in PHP itself. Sansec puts it plainly: the attack paths "run inside PHP, before your store code". Nothing in your website's own code can stop it. The fix has to be made to the server.

The flaws need no login and affect more than a decade of PHP releases. PHP says "there are no complete mitigations, updating is the only safe choice."

Is it being exploited?

Attacks have started. watchTowr says it is "observing active exploitation attempts of both CVE-2026-109618 and CVE-2026-109619", and Cloudflare saw early attempts on 21 October, before the fix was even released. watchTowr says sites running PHP inside Apache (mod_php) carry "the highest demonstrated risk".

As of 22 October, none of the sources we checked had reported a confirmed break-in. Sansec expects mass exploitation now that the fix and write-ups are public.

What should you do now?

1. Find out which PHP version your website runs. Your host or developer can tell you.
2. Check it is a fixed version: 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a build your host confirms includes the fix. Ubuntu and CloudLinux, for example, add the fix without changing the version number to match PHP's.
3. If it is not fixed, have it updated now. Then have any temporary upload block removed.
4. If your site runs PHP 8.1 or older, ask your host whether its build has been fixed. PHP no longer updates these versions, and many builds of them will stay vulnerable. Plan the upgrade either way.

Why updating is not the whole fix

If an attacker got in before the patch, updating PHP does not remove what they left behind. After patching, it is worth checking the site for files that should not be there, admin accounts nobody recognises, and changes to the home page.

An old PHP version is also a standing risk. Every future PHP flaw will hit it too, with no fix from PHP at all.

What this looks like with BLACKBX

On 21 October, ahead of the release, BLACKBX applied the interim settings and a temporary upload block across the servers it manages, and checked each one.

On 22 October we installed the fixed PHP builds, checked every PHP version on every server against the fixed list, removed the upload block on every patched server, and recorded the update, dated, in each client's logbook. Where a server cannot get a fixed build, because its operating system is past its support date, the interim protections stay in place and we have given the owner a plan to move it.

On the Monitor plan, findings like this go to the client's own developer with the version numbers and our advice, so they can act on them. On Maintenance and Full service, BLACKBX does the work. All plans are monthly, with no minimum term.

Timeline

Dates are in UTC, except BLACKBX's own actions, which are in Australian time.

Sources

• Security advisory: Critical remote code execution vulnerabilities, update now, PHP, 21 October 2026
• Critical vulnerabilities in PHP, ASD's ACSC, 21 October 2026
• USN-8948-1: PHP vulnerabilities, Ubuntu, 21 October 2026
• PHP CVE-2026-109618 and CVE-2026-109619, CloudLinux
• PHP remote code execution (PHP2Shell), watchTowr, 21 October 2026
• Critical PHP RCE: CVE-2026-109618 and CVE-2026-109619, Sansec
• PHP security announcement and upcoming patches, Silverstripe, 21 October 2026
• Critical Remote Code Execution Vulnerabilities in PHP (CVE-2026-109618 & CVE-2026-109619), Beazley Security Labs

Checked 22 October 2026 against php.net, the CMS projects' own documentation and endoflife.date. Sources are listed at the end.

What happens on 31 December 2026?

PHP is the programming language behind WordPress, Drupal, Magento, Silverstripe and many custom web applications. Every website built on one of those runs on a particular PHP version, chosen on the server.

Each PHP version has a fixed support period. PHP says each version is "fully supported for two years from its initial stable release", then "supported for two additional years for critical security issues only."

PHP 8.2 was released on 8 December 2022. Its full support (bug fixes as well as security fixes) ended on 31 December 2024, and its security support ends on 31 December 2026. In PHP's 21 October 2026 release announcement: "PHP 8.2 reaches end of life on 31 December 2026 and will receive no further security fixes after that date. Please plan your upgrade to a supported version."

Your website will not stop working on 1 January. It will keep running exactly as it does now. What stops is the fixes. PHP's advice for versions past end of life is that users "should upgrade as soon as possible, as they may be exposed to unpatched security vulnerabilities."

What October's PHP flaws showed

On 21 October 2026 PHP fixed two critical flaws, CVE-2026-109618 and CVE-2026-109619, which let an attacker take over a web server without logging in. PHP released fixed versions for every supported version: 8.5, 8.4, 8.3 and 8.2. PHP 8.2 got PHP 8.2.35, because it still has security support.

PHP 8.1 and older did not get a release. PHP's advisory says: "PHP 8.1 and older no longer receive updates from the PHP project." Because the flaws were so serious, PHP's security team also published source code fixes for 7.4, 8.0 and 8.1, for people who build PHP themselves, and some vendors released their own fixed copies. Everyone else on those older versions has to rely on their host or vendor for a fix.

After 31 December, a site on PHP 8.2 is in that same position for the next serious flaw. Whether PHP's security team would make an exception again is not something anyone can plan on.

Which PHP versions are supported, and until when?

These are PHP's own dates, from php.net.

Full support means PHP fixes bugs as well as security issues. PHP 8.4's full support ends on 31 December 2026 too, but that is not end of life: it keeps receiving security fixes for two more years.

How do I find out which PHP version my website runs?

• Ask your host or developer. Ask two questions: which PHP version does the site run, and does the host's copy of PHP still receive security fixes, and until when?
• If your hosting has cPanel, and your host has turned on MultiPHP Manager (under Software), that page lists each domain and the PHP version it uses. Look, but do not change the version there: switching PHP without testing first can break a site.
• Do not judge by the version number alone. Some hosts, and server operating systems such as Ubuntu, fix the version they already ship without changing its number to match PHP's. PHP itself notes that some vendors provide their own fixes for older versions. For example, Ubuntu fixed the October flaws in its own copies of PHP 8.3 on Ubuntu 24.04 and PHP 8.1 on Ubuntu 22.04. Only your host can tell you how long its copy of PHP 8.2 will keep receiving fixes, so ask.

Why upgrading PHP often means upgrading the CMS too

Each version of a content management system (CMS) supports a set range of PHP versions. If yours does not support a newer PHP, the CMS has to be upgraded first, or at the same time. These are the projects' own published ranges:

• WordPress. WordPress 7.1 lists PHP 7.4 to 8.5 as supported, and WordPress recommends "PHP version 8.3 or greater." For WordPress itself the move is usually straightforward. The work is in the theme and plugins: each one has to run on the new PHP version.
• Drupal. Drupal 10.4 to 10.6 support PHP 8.1 to 8.4. Drupal 11 lists PHP 8.3 and newer only, with 11.3 and 11.4 also supporting 8.5. Drupal 10 itself reaches end of life on 9 December 2026, three weeks before PHP 8.2, so a Drupal 10 site has two deadlines this December. Drupal 7 has been end of life since 5 January 2025 and "will no longer receive security or compatibility updates."
• Magento (Adobe Commerce). Adobe's system requirements list PHP 8.2 and 8.1 for Magento 2.4.6, 8.3 and 8.2 for 2.4.7, 8.4 and 8.3 for 2.4.8, and 8.5 for 2.4.9. A store on 2.4.6 cannot move off PHP 8.2 without upgrading Magento as well.
• Silverstripe. Silverstripe CMS 4 supports PHP 7.4 to 8.1, so it already runs on a PHP version past end of life, and Silverstripe 4 itself reached end of life on 10 June 2025. The way forward for those sites is a Silverstripe upgrade, and Silverstripe 6 gives the longer runway. Silverstripe 5.4 supports PHP 8.1 to 8.3, and its own security support ends on 30 April 2027. Silverstripe 6.2 supports PHP 8.3 to 8.5. Silverstripe's policy is that "When a PHP version reaches end-of-life, Silverstripe CMS drops support for it in the next minor release", so keeping Silverstripe up to date and keeping PHP supported go together.
• Custom applications. It depends on the code and the frameworks and libraries it is built on. A developer needs to check them against the new PHP version.

Which PHP version should I move to?

The newest PHP version that is still supported by PHP and by your CMS version, because it stays supported the longest. If your CMS version stops at PHP 8.2 or older (Silverstripe 4, Magento 2.4.6, Drupal 7), the CMS needs upgrading as part of the move.

For most sites today that is PHP 8.4, supported until 31 December 2028, or PHP 8.3 where the CMS stops there. Magento 2.4.8 goes up to 8.4, Magento 2.4.7 and Silverstripe 5.4 go up to 8.3. Drupal 10 also supports 8.4, but Drupal 10 itself ends on 9 December 2026, so a Drupal 10 site should plan the move to Drupal 11 (PHP 8.3 or newer) at the same time. PHP 8.3 only buys one more year: its support ends on 31 December 2027, so plan the next step at the same time.

Where your CMS version supports PHP 8.5 (WordPress 7.1, Drupal 11.3 and 11.4, Silverstripe 6.2, Magento 2.4.9), 8.5 stays supported longest, to 31 December 2029, provided the site's plugins, modules and custom code support it too.

What does a PHP upgrade involve?

At a high level, the same steps for any site:

1. Check the site's code, theme, plugins, modules and extensions against the new PHP version, and the CMS version against its supported range.
2. Update whatever needs it. Sometimes that is a few plugins; sometimes it is the CMS itself.
3. Test on a copy of the site running the new PHP version: forms, logins, checkout, integrations and anything that runs on a schedule.
4. Switch the live site over, check it again, and keep the old version available in case something needs to be rolled back.

How much work that is depends entirely on the site. A site that has been kept up to date may need little more than checking and testing. An older site, or one on a CMS version past its own end of life, will need more.

What should you do now?

1. Find out which PHP version your website runs. Your host or developer can tell you.
2. If it is PHP 8.2, ask your host whether its copy of PHP 8.2 will receive security fixes after 31 December 2026, and until when.
3. Ask your developer which supported PHP version your CMS version runs on, and what has to change to get there.
4. Schedule the upgrade, with testing on a copy, before 31 December. December is busy for most businesses and developers, so leave room.
5. If your site runs PHP 8.1 or older, or a CMS version past end of life such as Silverstripe 4 or Drupal 7, put it first: it is already in the position PHP 8.2 will be in.

What this looks like with BLACKBX

BLACKBX looks after existing websites built on WordPress, Drupal, Magento, Silverstripe and custom applications.

On Maintenance and Full service, BLACKBX does the work. On Monitor, findings like this go to your own developer, so they can plan it. Upgrade work is quoted after one of our developers has looked at your site, because no two sites need the same work: see PHP and CMS upgrades. Maintenance starts from $840 a month + GST, and all plans are monthly, with no minimum term. Every change is recorded, dated, in a logbook you own.

Not sure where your site stands? Start with the free website health check at app.blackbx.com.au/inspect, or get in touch below to book a 20-minute call with a developer about your site.

Sources

• Supported versions, PHP, checked 22 October 2026
• Unsupported branches, PHP, checked 22 October 2026
• PHP 8.2.35 released, and Security advisory: Critical remote code execution vulnerabilities, update now, PHP, 21 October 2026
• USN-8948-1: PHP vulnerabilities, Ubuntu, 21 October 2026
• MultiPHP Manager for cPanel, cPanel documentation
• PHP compatibility and WordPress versions, WordPress Core Handbook
• Requirements, WordPress.org
• PHP requirements, Drupal.org
• Drupal core release schedule, Drupal.org
• Drupal 7 end of life, Drupal.org
• System requirements, Adobe Commerce documentation
• Server requirements, Silverstripe CMS 4, Silverstripe documentation
• Server requirements, Silverstripe CMS 5, Silverstripe documentation
• Server requirements, Silverstripe CMS 6, Silverstripe documentation
• Silverstripe CMS release dates and support, endoflife.date, checked 22 October 2026