FDM Software LabsInsert Idea. Press Enter.FindBuild your package
Menu

How we build

Security holes in the news

Every day we read two public lists of new security holes. One is the US government's database of reported holes. The other is a list from CISA, the US cybersecurity agency, of holes already being used in attacks. Thousands are reported a year, so this page is not a full list. It keeps the serious ones in website software, the kind that could reach a site like yours. For each one we check whether it reaches the sites we build, then write the answer here: what it was, who it put at risk, and why it did or didn't reach ours. If one ever does, we post that too after the fix, with what we did and how long it took.

  1. Doesn't reach our sites

    A hole in the Sentry add-on for Next.js

    Who it put at risk
    Sites that use the @sentry/nextjs add-on, in versions 9.36.0 up to but not including 9.47.2, 10.0.0-alpha.0 up to but not including 10.75.2, or 11.0.0-alpha.0 up to but not including 11.0.0-rc.1, and set up as described under What happened.
    How serious
    9.1 out of 10, rated critical by GitHub
    Fixed by
    The @sentry/nextjs package's updates to versions 9.47.2, 10.75.2 and 11.0.0-rc.1

    What happened. This is not a hole in Next.js. It is in @sentry/nextjs, an add-on that sends a site's error reports to the Sentry service. Its tunnel option sends those reports through the site's own address, and the add-on skipped the site's middleware (a step that runs before a page loads, often to check who is signed in) for every address under the tunnel's. That skip was too wide. Someone with no account could reach a page unchecked, but only if all four were true: the tunnel was on; the site was built with webpack, a build tool; a page address sat under the tunnel's; and middleware was the only sign-in check.

    Our sites. None of the sites we've built were on a version with this hole.

    How we know. On Oct 22, 2026 we checked the full list of packages (ready-made pieces of code) behind every site we've built, and behind the starting copy every new site is made from, against a public database of known holes. Nothing we use matched this hole.

    Sources: The US vulnerability database

  2. Doesn't reach our sites

    PHP Memory Corruption Vulnerability

    Who it put at risk
    Websites that run on PHP (versions from 7.3.0 up to, but not including, 8.2.35, from 8.3.0 up to, but not including, 8.3.36, from 8.4.0 up to, but not including, 8.4.27 and from 8.5.0 up to, but not including, 8.5.12)
    How serious
    9.2 out of 10, rated critical by PHP. CISA, the US government's cybersecurity agency, lists it as already being used in attacks.
    Fixed by
    PHP's updates to versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12

    What happened. PHP contains an out-of-memory corruption vulnerability that allows for unauthenticated remote code execution.

    Our sites. None of the sites we've built run PHP.

    How we know. On Oct 27, 2026 we checked the full list of packages (ready-made pieces of code) behind every site we've built, and behind the starting copy every new site is made from, against a public database of known holes. Nothing we use matched this hole. We also searched the name of every file in our code for signs of PHP, and found none.

    Sources: The US vulnerability database CISA's list The maker's notice

  3. Doesn't reach our sites

    PHP Stale Internal Request-State Vulnerability

    Who it put at risk
    Websites that run on PHP (versions from 5.4.0 up to, but not including, 8.2.35, from 8.3.0 up to, but not including, 8.3.36, from 8.4.0 up to, but not including, 8.4.27 and from 8.5.0 up to, but not including, 8.5.12)
    How serious
    9.2 out of 10, rated critical by PHP. CISA, the US government's cybersecurity agency, lists it as already being used in attacks.
    Fixed by
    PHP's updates to versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12

    What happened. PHP contains a stale internal request-state vulnerability that allows for unauthenticated remote code execution.

    Our sites. None of the sites we've built run PHP.

    How we know. On Oct 27, 2026 we checked the full list of packages (ready-made pieces of code) behind every site we've built, and behind the starting copy every new site is made from, against a public database of known holes. Nothing we use matched this hole. We also searched the name of every file in our code for signs of PHP, and found none.

    Sources: The US vulnerability database CISA's list The maker's notice

  4. Doesn't reach our sites

    PHP2Shell: two holes in PHP

    Who it put at risk
    Websites that run on PHP, including WordPress, Drupal and Joomla sites and Magento shops
    How serious
    9.2 out of 10, by PHP's own rating
    Fixed by
    PHP's update of Oct 21, 2026

    What happened. PHP is a programming language that runs on the computer that hosts a website (its server) and builds each page when someone visits. By one security firm's count it is behind 70% of the world's websites. Two holes in PHP itself let a stranger with no account make the server run their own instructions. Attackers were already trying them before the fix came out. No break-in had been confirmed when it was reported, but every website on PHP needed the update.

    Our sites. None of our sites run PHP. Every page is a finished file before anyone asks for it, so nothing builds pages on a server when you visit. The service behind our forms and sign-ins, Supabase, is built in other languages, not PHP.

    How we know. On Oct 22, 2026 we searched the code of every site we've built, and the starting copy every new site is made from. We found no PHP files and nothing that runs PHP.

    Sources: Help Net Security The Hacker News Wiz Sansec SecurityWeek Supabase's parts

  5. Doesn't reach our sites

    A hole in zod, a tool we build with

    Who it put at risk
    People who build websites with the zod package (versions before 4.6.6)
    How serious
    Rated high by GitHub
    Fixed by
    The zod package's update to version 4.6.6

    What happened. Zod schema-validation library contains an uncontrolled resource consumption vulnerability that allows attackers to exhaust memory by submitting a large array, set or map to an application that uses a container schema without an explicit size constraint. The handleArrayResult parse logic in $ZodArray (and the equivalent set and map paths) accumulates every validation issue for each failing element with no cap or early termination, causing the process to allocate one issue object per element and crash under out-of-memory conditions.

    Our sites. It was in a tool we use to build our sites. No live site ran it.

    How we know. On Oct 24, 2026 we checked the full list of packages (ready-made pieces of code) behind every site we've built, and behind the starting copy every new site is made from, against a public database of known holes. The zod package came up, but only as a build tool, a program used while a site is put together. By Oct 24, 2026 we had updated it.

    Sources: The open-source hole database The US vulnerability database

  6. Doesn't reach our sites

    wp2shell: two holes in WordPress

    Who it put at risk
    WordPress websites on versions 6.9 and 7.0
    How serious
    9.8 and 5.9 out of 10, by WPScan, the WordPress security firm that filed them. WordPress called them one critical and one high.
    Fixed by
    WordPress's update of Jul 17, 2026

    What happened. WordPress is a widely used tool for building and editing websites. Two holes in WordPress itself, used together, let a stranger with no account slip commands into the site's database (where it keeps pages and accounts) and then make the server run their own instructions. CISA, the US government's cybersecurity agency, says it works on a plain WordPress site. WordPress pushed the fix to every site that takes automatic updates. Attack code was soon public, and CISA confirmed attacks four days after the fix.

    Our sites. None of our sites run WordPress, or PHP, the language it is written in. Every page is a finished file before anyone asks for it.

    How we know. On Oct 22, 2026 we searched the code of every site we've built, and the starting copy every new site is made from. We found no WordPress files and no PHP files.

    Sources: WordPress 7.0.2 Security Affairs CISA list

  7. Doesn't reach our sites

    A hole in the JCE editor for Joomla

    Who it put at risk
    Joomla websites using the JCE editor add-on
    How serious
    10 out of 10, by Joomla's security team
    Fixed by
    JCE's update of Jun 3, 2026 (version 2.9.99.5)

    What happened. JCE is an add-on for Joomla, a tool for building and editing websites. It gives Joomla an editor that works like a word processor. A hole in JCE let a stranger with no account add their own editor settings, set to accept program files, and then upload their own code. Attackers used it to leave a web shell, a hidden back door that lets them come back and control the site.

    Our sites. None of our sites run Joomla, its add-ons, or PHP, which Joomla is built on.

    How we know. On Oct 22, 2026 we searched every site we've built, and the starting copy every new site is made from, for Joomla and PHP files. There were none.

    Sources: JCE notice The Hacker News NVD

  8. Doesn't reach our sites

    TanStack: poisoned code in a public library for developers

    Who it put at risk
    Developers, and the computers that build their sites, who installed TanStack's router code that day
    How serious
    9.6 out of 10, in TanStack's own security notice
    Fixed by
    npm removed the bad copies the same day, May 11, 2026

    What happened. Most modern websites are built from ready-made pieces of code, called packages, that developers download from npm, a public online library of JavaScript, a common web language. TanStack makes some of them. On May 11, 2026 an attacker put 84 poisoned versions of 42 TanStack packages into npm, in six minutes. Installing one ran a program that stole passwords and secret access keys from the developer's computer or the computer that builds their site. CISA lists it as used in ransomware attacks, where criminals lock up a victim's files and demand money.

    Our sites. Our sites are built from npm packages too, so this is the kind of hole that could reach us. None of our sites uses a TanStack package.

    How we know. On Oct 22, 2026 we checked the full list of packages behind every site we've built, and the starting copy every new site is made from. No TanStack package is on any list, and a public database of known holes and bad packages matched nothing we use.

    Sources: TanStack's account TanStack's notice CISA list

  9. Doesn't reach our sites

    A hole in the cPanel login

    Who it put at risk
    Websites on web hosts that use cPanel
    How serious
    9.8 out of 10, by VulnCheck, the security firm that filed it
    Fixed by
    cPanel's update of Apr 28, 2026

    What happened. Many web hosts, the companies that keep sites online, give their customers cPanel, a control panel for running websites, email and files. A hole in its login let a stranger get in without a password, and from there control the server and the websites on it. Attackers were using it from February 23, two months before the fix. CISA lists it as used in ransomware attacks.

    Our sites. None of our sites use cPanel. Each is a set of finished files that Cloudflare, the company that hosts them, hands to visitors. We have no server with a control panel to log in to.

    How we know. On Oct 22, 2026 we checked the settings of every site we've built, and the starting copy every new site is made from. Each is set to build finished files served by Cloudflare, and none holds cPanel files.

    Sources: cPanel update Help Net Security CISA list

  10. Doesn't reach our sites

    SessionReaper: a hole in Adobe Commerce and Magento

    Who it put at risk
    Online shops on Adobe Commerce or Magento
    How serious
    9.1 out of 10, by Adobe's own rating
    Fixed by
    Adobe's urgent fix of Sep 9, 2025

    What happened. Adobe Commerce, and its free version Magento, is software for running an online shop. A hole let a stranger take over shoppers' accounts. Researchers showed it could also make the shop's server run their own instructions. Six weeks after the fix, one security firm blocked over 250 attack attempts in a day. By one count, only 38% of Magento shops had installed the fix by then.

    Our sites. None of our sites run on Adobe Commerce, Magento or PHP. Our forms and sign-ins go through Supabase, the service behind them, which is built in other languages.

    How we know. On Oct 22, 2026 we searched the code of every site we've built, and the starting copy every new site is made from. We found no Magento files and no PHP files.

    Sources: Adobe bulletin APSB25-88 Help Net Security Dark Reading