One of the private keys was the number 4

Field Log // 042 Status Live Difficulty Free Cost Nothing

The Story

Nine items, and the biggest log this site has run. Eight certificate authority private keys turned out to be single byte numbers, one of them the number 4, and they were effectively public for seventeen months. PHP has an emergency release landing today for two critical flaws whose details leaked before the patch. One person used automated agents to break into more than a hundred companies for roughly the price of a used laptop. And three separate supply chain attacks this month had windows measured in minutes, which is the argument I want to end on, because that brevity is deliberate.

One. PHP has an out of cycle security release today, and the details got out first. On 20 October PHP gave advance notice of an emergency security release scheduled for today, 21 October, at 14:00 UTC, fixing two critical vulnerabilities both rated CVSS v4.0 9.2. Researchers are calling the pair PHP2Shell and describe them as remote code execution. The reason PHP announced ahead of time at all is that details leaked ahead of embargo, which forced the early notice. Sansec says they affect all web servers running PHP 5.4 or later, which is essentially every PHP deployment in existence. PHP runs WordPress, Drupal, Magento and a large share of the web, so this is one of the few items where the affected population is close to everybody.

What to do before it lands, which is the only useful advice while this is still pending. Know what PHP version you are on, and know it for every host rather than the one you remember. Be ready to update the moment the release appears rather than starting to find out your version then. If you are on an end of life branch, understand now that no official fix is coming for you and plan accordingly. And do not go hunting for and running leaked proof of concept code, which is a genuinely bad idea with an unpatched 9.2 on your own infrastructure.

This is where most of the coverage is overreaching, so here is what PHP has actually said versus what is circulating. PHP's official announcement names no CVE identifiers, no affected branches and no fixed versions. It says those publish with the release. The identifiers going around, CVE-2026-109618 and CVE-2026-109619, come from researchers rather than from PHP, so treat them as researcher attributed until the release lands. No in the wild exploitation has been reported, so nobody should be telling you this is being exploited right now. And PHP said it may release earlier than planned if details go fully public or exploitation starts, so 14:00 UTC was a plan rather than a guarantee. Check php.net rather than any secondhand timeline, including this one.

The frame worth keeping: this is the rare case where the warning arrived before the attack. Most of what this site reports is the reverse order.

Two. Eight certificate authority private keys that were single byte numbers. This is the best story of the month and I am going to give it room. Researcher Scott Helme found that eight eMudhra intermediate certificate authority private keys were not random 384 bit numbers, as P-384 keys are supposed to be. They were small integers. Helme published the actual values, and they are in The Build below, because reading them as a list is the whole experience. One of them is 4. Helme pulled all sixteen affected certificates and brute forced every key in under a second.

The keys were created in April 2025 and cross signed by Sectigo's AAA Certificate Services root in May 2025, which means they were effectively public for roughly seventeen months. What possession of those keys permits is forging a valid certificate for any domain that chains to those intermediates. Helme demonstrated it, producing a certificate for api.stripe.com that curl, Python and Node accepted by default on Linux and macOS. Two of the eight are code signing keys, which means malware could have been signed to look like it came from a legitimate publisher.

The cause, per eMudhra's own account on Mozilla's bug tracker, is almost reassuringly ordinary: a bug in the key ceremony script created a second, weak key pair on the hardware security module, and because the keys had similar names the wrong one was used for the certificate signing request. Not a broken algorithm and not a compromised facility. A naming collision in a script, inside the most ceremonially careful process the industry has.

The response was fast once it was known. Chrome shipped a CRLSet block on 17 October, Mozilla followed with OneCRL hours later, Apple acted on 19 October and Microsoft on 20 October. Mozilla shipped an NSS update removing the root, and Chrome removes it in Root Store version 43. The Go team shipped an emergency release, 1.27.3 and 1.26.10, rejecting chains through those keys.

Here is the nuance that makes this worth your time rather than just worth a laugh. If you browse the web, you are largely fine: browsers blocked this within days and they enforce Certificate Transparency, which is why nothing anomalous has turned up in the logs. What is not protected is everything else. Servers. Internet of things devices. Software update systems. Non browser TLS clients. Windows CryptoAPI when revocation checking is not on. Those all depend on certificate authority bundles that somebody updates by hand, and most of them nobody updates at all. And devices with frozen firmware will keep trusting these authorities until the certificates expire in July 2039, which is thirteen more years. The browser is the one part of this ecosystem with a working emergency brake, and it is the part that was never the problem.

The practical work is unglamorous. Update the operating system ca-certificates package, update certifi, update Node and any other language or runtime shipping its own certificate authority bundle, and rebuild container images, because a container built last month carries last month's bundle no matter how current the host is. And the obvious one that still needs saying: do not fix a certificate error by disabling verification. That turns a detection into a permanent hole.

I am not claiming anyone used these keys maliciously, and neither is Helme. Nothing anomalous has been found in Certificate Transparency logs. The story is not that this happened to you. The story is that it was possible for seventeen months and nobody noticed, including the browsers, the root programs and the auditors. Helme does note that a single prompt to an AI assistant was enough to recover the keys, and I am including that only as his observation about how trivial the underlying arithmetic was. It is a one line detail about the size of the numbers, not a story about AI security.

Three. One person, automated agents, more than a hundred companies, about five thousand dollars. This comes from a Reuters investigation plus original research by NorForge. A Chinese speaking operator pointed AI agents at more than 1,200 websites and got into more than 100 companies. Named victims include Deere, SharkNinja and Cummins. On cost, a researcher estimated roughly $5,000 in tokens in total, which works out to about $50 per successful break in, and that was explicitly offered as a rough estimate. NorForge's own figure is around $5 per task including failures, also with considerable stated uncertainty. Successful attacks averaged a little under 23 hours, running unattended.

How it was found is the part I enjoy most. The operator left the agents' control panels open on the internet. Researcher Snorre Fagerland found them with ordinary internet scanning starting around 2 October, for a campaign that began on 25 September. More than 20 panels were judged likely malicious and grouped into three clusters. Those panels also exposed hundreds of credentials and API keys the agents had harvested, of which 11 percent were verified as still valid.

The responses, for completeness. Deere took remediation steps and saw no sign that sensitive information was accessed. SharkNinja said it hit a standalone product support site and was contained. Cummins said it was looking into a possible attack on a vendor run website. And the author of the open source agent platform involved said it was not built for this and that harmful use is not their intent.

Three things I will not tell you about this, and the third one is the most important claim in this entire log. There is no precise breach count: more than 1,200 sites attempted, more than 100 breached, and no exact figure exists. There is no established data theft, because Reuters could not establish how much data, if any, was actually taken. And I am not naming which AI model was used, because nobody knows. The research infers a model combination from a worker name found in the tooling and explicitly labels that an inference rather than a finding. Naming a vendor's product as the weapon here would be repeating somebody's guess as a fact, and it is the kind of error that discredits a whole page to anyone who goes and reads the actual report. So: automated agents, an open source agent platform, and an unidentified model behind them.

The takeaway is uncomfortable and it is not about AI capability. What the attacker needed was a payment method and patience, not skill. And they were caught because they left their own dashboard exposed on the open internet, which is precisely the same mistake their victims made.

Four. The record Patch Tuesday, what is actually new since we covered it. We reported this one in log 036, including the part everybody gets wrong: four organisations counted it and got 1,407, 1,411, 1,413 and 1,415, and none of them is wrong because they draw the boundary in different places. That analysis stands and I am not going to restate it with a different set of attributions, because more outlets have since landed on the same spread and the only honest version is the one that says whose count it is. Go and read log 036 for that. Here is what has been added since.

Tenable's full breakdown: 1,407 CVEs across 301 patched products and components, of which 69 are Critical, 1,337 Important and exactly 1 Low. Roughly 48 percent are elevation of privilege and 22 percent remote code execution. It was also the second consecutive record month, which is the trend rather than the event.

Two more flaws worth separating carefully. CVE-2026-108398, a .NET Framework security bypass, was publicly disclosed before a patch existed. It is not stated as exploited, so do not read it as a second zero day. And among the Critical items rated Exploitation More Likely there is an Active Directory Domain Services remote code execution, CVE-2026-70229, plus two Exchange Server flaws, CVE-2026-70279 and CVE-2026-70571. Exploitation More Likely is Microsoft's own forecast rather than an observation, but on domain controllers and Exchange it is the forecast worth acting on.

And the end of support cliff arrived in the same month, which is the quieter half of this item. Extended Security Updates ended for Windows Server 2012 and 2012 R2. Extended support ended for Windows 10 Enterprise 2016 LTSB. Windows Server 2022 moved to extended support. Office 2021 and Windows 11 Home and Pro 24H2 reached end of support. Every one of those means a machine that will keep working and stop being fixed.

The point I would make about a number that large: 1,407 patches is not 1,407 emergencies. One of them was actually being exploited. The useful skill is knowing which one matters, and a figure that big actively prevents people from finding it, because it reads as a wall rather than a list. The exploited one was CVE-2026-96951, the Windows Shell Mark of the Web bypass we covered in log 036. If you only do one thing from this item, that is the one.

Five. Three things from yesterday's log are now officially confirmed as under attack. CISA added six vulnerabilities to the Known Exploited Vulnerabilities catalog on 20 October, and most of them are stories already on this site. The four Plex Media Server flaws forming the Plex2Shell chain, which were item one of log 041 yesterday. Siemens Software Center CVE-2026-110936, item three of the same log. And SiteGuard Server Edition CVE-2026-106931, which we have not covered before and which matters again in item nine below.

A KEV listing means the United States government has evidence of real exploitation, and federal agencies get a remediation deadline attached to it. That closes a loop on the Plex story in particular: yesterday we reported it as researcher observed exploitation, and it is now formally confirmed by the government. The fixes have not changed. Plex Media Server 1.43.3.10861 or later, Siemens Software Center 4.0.9.8 or later, and SiteGuard per the vendor. I am not printing the federal remediation due dates, because I could not load CISA's own alert page to confirm them, and a wrong compliance date is worse than no date. The six CVEs and the fact of the listing are solid.

Six. Ransomware crews are still getting in through a firewall flaw patched in May. Unit 42 reports Qilin, which it tracks as Spikey Scorpius, and INC, which it tracks as Tarnished Scorpius, exploiting CVE-2026-0257, an authentication bypass in Palo Alto PAN-OS and Prisma Access rated CVSS 7.8, to establish unauthorized VPN sessions and bypass multi factor authentication. Note the dates. Patched May 2026. In CISA's KEV catalog since 13 May. Still working in October. ReliaQuest has also reported Qilin and Settra using it, and Arctic Wolf first flagged Qilin's use back in July. This is a different PAN-OS flaw from the CVE-2026-0322 we covered in log 037, which needed a privileged administrator already.

The chain after access is conventional and worth knowing in order: get a foothold, bypass multi factor authentication for a VPN session, run internal reconnaissance using dual use remote monitoring and management tools, move laterally over RDP and SMB, then stage credential harvesting, exfiltration and ransomware. Sectors hit include education, financial services, healthcare, technology, hospitality, manufacturing, professional and legal services, government, transportation and logistics, utilities and energy, and retail, which is close enough to everything that the sector list is not a filter.

The escalation in one of these cases is the part I want to explain properly, because it defeats a control most people assume is working. They pivoted from the VPN gateway to the vCenter management appliance, disabled security controls on the ESXi hypervisors, and then used a custom tool to dump credentials offline from a domain controller's virtual disk file. Read that last step again. They did not attack the domain controller. They read its disk from underneath its operating system, so the endpoint detection agent running inside that domain controller never saw anything, because from the guest's point of view nothing happened. That is domain wide credential theft with no in guest detection available at all. They also chained to Veeam CVE-2023-27532 to reach backup infrastructure, which is the other half of the same idea: go at the layer below the thing that is watching.

The lesson is narrow and worth stating plainly. Multi factor authentication is not a wall if the thing standing in front of it can be bypassed, and a May patch only helps the people who installed it. The reporting does not list specific affected PAN-OS versions, so I am not giving you a version range here. Check your own against the vendor advisory.

Seven. Another developer tool poisoned, this time for 94 minutes. An attacker used a hijacked contributor's GitHub account to replace the download archives on five existing OVHcloud CLI releases, versions 0.11.0 through 0.15.0, with builds that steal secrets from disk. The tag, the source code and the build pipeline were all untouched, which is why this is hard to notice. The window was 19 October from 12:47 to 14:21 UTC, so up to 94 minutes. The exposed paths were the install script, manual downloads, unpinned continuous integration jobs, and the CLI's own upgrade command on macOS and Linux.

Who was safe is the instructive part, and it is a short list of specific technical decisions rather than luck. Homebrew users were fine, because the cask pinned the original file hashes, so the swapped archive simply failed to match. Anyone who built from source or used go install was fine, because the tag was never changed. Docker users were fine, because the image had not been rebuilt during the window. And anyone who installed before the window and did not update was fine, which is the one time this year that procrastination was a security control. Every one of those is a form of pinning or verification. None of them is vigilance.

The root cause, stated by OVHcloud: GitHub release immutability was not enabled, so a user with write access could replace files on an already published release with no continuous integration checks in the way. It is enabled now. For remediation, rotate every secret readable from a machine that may have run a swapped build, and do that rotation from a different machine, because the machine you are worried about is the wrong place to type new credentials. Then remove the binary and install the immutable 0.16.0.

I am not naming an attacker for this one. Researchers linked the compromised account to an existing campaign but explicitly call that their inference. No copy of the malicious binary was preserved, which is a real gap: OVHcloud has not said how the credentials were taken, what the binary actually read, where it sent data, or how many copies were downloaded. That is a lot of unknowns, and they are unknowns rather than things being withheld.

Eight. A ransomware group with more than 600 victims that goes after the backups first. CISA, the FBI, the Secret Service and partners in Germany and the United Kingdom issued joint advisory AA26-293A on 20 October covering SafePay ransomware. Active since August 2024, among the most active groups of 2026, with more than 600 victims across multiple critical infrastructure sectors. Initial access comes from stolen or guessed credentials, phishing, and known vulnerabilities on internet facing devices, with the reporting specifically highlighting VPN appliances and backup servers. Lateral movement uses legitimate administration tools, which is what makes them hard to spot, because the tools are the ones your administrators also use. Extortion runs through encryption, a leak site and phone calls.

The mitigations are unglamorous and the same every time: patch edge devices, enforce multi factor authentication, limit administrative access, segment networks, and maintain tested, immutable, offline backups. That last one is the whole game against a group whose documented preference is to go at backup infrastructure before anything else. Note that backup servers appear twice in this item, once as an entry point and once as the thing that saves you, which is the tension worth designing around.

Nine. A security monitoring product now has public exploit code. FortiSIEM, CVE-2026-106173. An unauthenticated path traversal in the phQueryMaster gRPC service on TCP 27918, allowing an arbitrary file write that chains into remote code execution. Fortinet rates it 9.4 and patched it on 13 October under FG-IR-26-180. Horizon3.ai published a technical write up and a proof of concept on 20 October. There is no confirmed in the wild exploitation and it is not in KEV yet.

But the Plex precedent in yesterday's log is exactly one day old: details public on 16 October, attacks within about a day. A public proof of concept against a security product is a countdown, not a research note. The fix is upgrading to the patched releases, and the interim measure is restricting access to TCP 27918 from untrusted networks, which you should probably be doing anyway for a query service on a monitoring appliance.

Pair this with the SiteGuard entry in item five above, which is a web application firewall that was handing out root and is now confirmed as being exploited. Two security products in two weeks, both of them the thing you installed in order to be safer. A firewall, a security information and event management platform, a backup server, a VPN appliance: the four items in this log that involve security or infrastructure products all involve the product being the way in. Defensive software is software. It parses untrusted input, it runs with high privilege, it sits at the edge, and it gets patched on the same schedule as everything else. The category is not exempt and arguably has the worst exposure profile in the building.

The Build

1. PHP: what to do before 14:00 UTC today

The release is pending as this is written, so the only work available is preparation. Check php.net for the actual release rather than any secondhand timeline, because PHP said it may ship earlier than planned.

# what PHP has actually said
#   out-of-cycle release, 2026-10-21 14:00 UTC (a PLAN, not a guarantee)
#   two critical vulnerabilities, both CVSS v4.0 9.2, described as RCE
#   NO CVE IDs, NO affected branches, NO fixed versions in the announcement.
#   those publish WITH the release.

# circulating but NOT from PHP (researcher-attributed):
#   CVE-2026-109618  CVE-2026-109619   "PHP2Shell"
#   Sansec: affects all web servers running PHP 5.4 or later

# prepare now
#   know your PHP version. on EVERY host, not the one you remember.
php -v
php -r 'echo PHP_VERSION, "\n";'

#   find every PHP that is actually serving
#   (fpm pools, cli, containers, and whatever the control panel installed)
ls /etc/php/
systemctl list-units '*php*'

#   on an END-OF-LIFE branch? no official fix is coming. plan for that now.

# NO in-the-wild exploitation reported. do not go running leaked PoC code
# against your own unpatched 9.2.

2. The eight eMudhra keys, as published

These are P-384 keys, where the private key is supposed to be a random 384 bit number. Read the right hand column. Scott Helme pulled all sixteen affected certificates and brute forced every one of these in under a second.

# intermediate CA                type           private key
EM DV TLS CA - G3B              TLS            156
EM DV TLS CA - G3C              TLS            230
EM EV TLS CA - G3B              TLS            115
EM EV TLS CA - G3C              TLS             56
EM OV TLS CA - G3B              TLS            155
EM OV TLS CA - G3C              TLS              4
EM OV CS CA - G3B               code signing    66
EM OV CS CA - G3C               code signing   237

# created April 2025. cross-signed by Sectigo AAA Certificate Services
# root in May 2025. effectively public for ~17 months.
# the last two are CODE SIGNING keys.

# root program response
#   Chrome CRLSet block     2026-10-17   (removed in Root Store v43)
#   Mozilla OneCRL          2026-10-17   (+ NSS update removing the root)
#   Apple                   2026-10-19
#   Microsoft               2026-10-20
#   Go emergency release    1.27.3 / 1.26.10  (rejects these chains)

# YOUR work, because the browser fix does not reach any of this:
#   OS trust store
apt update && apt install --only-upgrade ca-certificates   # debian/ubuntu
dnf update ca-certificates                                  # rhel/fedora
#   language runtimes that ship their OWN bundle
pip install --upgrade certifi
npm update                                                  # and check pinned CA bundles
#   REBUILD container images. a month-old image has a month-old bundle,
#   no matter how current the host is.

# NOT protected by the browser fix: servers, IoT, software update systems,
# non-browser TLS clients, Windows CryptoAPI without revocation checking.
# frozen-firmware devices keep trusting these until the certs expire 2039-07.

# and the obvious one: do NOT "fix" a cert error by disabling verification.

3. The agent campaign: what is known and what is inference

This item is mostly about reading the research honestly, because the interesting claim is also the unsupported one. The operational lesson is in the harvested credentials rather than in the agents.

# established
#   1,200+ websites attacked, 100+ companies breached
#   named victims: Deere, SharkNinja, Cummins
#   campaign began 2026-09-25; panels found by scanning from ~2026-10-02
#   20+ control panels judged likely malicious, in three clusters
#   successful attacks averaged a little under 23 hours, unattended
#   the panels leaked hundreds of harvested credentials and API keys
#   11% of those were verified STILL VALID

# estimates, stated as estimates by their authors
#   ~$5,000 in tokens total, ~$50 per successful break-in (rough)
#   NorForge: ~$5 per task including failures (high uncertainty)

# NOT established. do not repeat as fact.
#   a precise breach count
#   that data was stolen. Reuters could not establish how much, if any.
#   WHICH AI MODEL. inferred from a worker name in the tooling, and the
#   research labels it an inference. no vendor's product is the named weapon.

# the actionable bit, and it has nothing to do with AI:
#   11% of leaked keys were still live. rotate credentials on any
#   internet-facing site you cannot account for, and expire them on a
#   schedule so a harvest from September is worthless in October.

4. Patch Tuesday: the one that was actually exploited

The count dispute is in log 036 and still stands. What is new here is Tenable's breakdown, one more pre disclosed flaw, three forecast risks and the end of support dates.

# Tenable's breakdown (cite whose count you are using, always)
#   1,407 CVEs across 301 patched products and components
#   69 Critical / 1,337 Important / 1 Low
#   ~48% elevation of privilege, 22% remote code execution
#   second consecutive record month

# EXPLOITED (one). this is the one that matters.
#   CVE-2026-96951   Windows Shell, Mark of the Web bypass, CVSS 8.8
#   covered in log 036. third Windows Shell flaw exploited ITW in 2026.

# publicly disclosed before a patch existed. NOT stated as exploited.
#   CVE-2026-108398  .NET Framework security bypass

# Critical, rated "Exploitation More Likely" (Microsoft's FORECAST):
#   CVE-2026-70229   Active Directory Domain Services RCE
#   CVE-2026-70279   Exchange Server
#   CVE-2026-70571   Exchange Server

# end of support, same month
#   Windows Server 2012 / 2012 R2      ESU ENDED
#   Windows 10 Enterprise 2016 LTSB    extended support ENDED
#   Windows Server 2022                moved to extended support
#   Office 2021                        end of support
#   Windows 11 Home and Pro 24H2       end of support

5. The six new KEV entries

Three of these are stories from the last two days of this site. A KEV listing means the US government has evidence of real exploitation, which is a higher bar than researcher observation.

# added to CISA KEV 2026-10-20
#   CVE-2026-96652  )
#   CVE-2026-96654  )  Plex Media Server, the Plex2Shell chain
#   CVE-2026-96655  )  -> log 041 item 1
#   CVE-2026-96656  )
#   CVE-2026-110936    Siemens Software Center  -> log 041 item 3
#   CVE-2026-106931    SiteGuard Server Edition (not previously covered)

# fixes, unchanged
#   Plex Media Server        1.43.3.10861 or later
#   Siemens Software Center  4.0.9.8 or later
#   SiteGuard                per vendor

# federal remediation due dates deliberately NOT printed here:
# CISA's alert page would not load to confirm them, and a wrong
# compliance date is worse than no date. check KEV directly.

6. PAN-OS CVE-2026-0257: patched in May, still being used in October

The notable part is the vCenter pivot, which reads a domain controller's disk from underneath its operating system so no in guest agent can see it. Plan detection at the hypervisor layer, not only inside the guest.

# the flaw
#   CVE-2026-0257   PAN-OS and Prisma Access, auth bypass, CVSS 7.8
#   -> unauthorized VPN sessions, bypasses MFA
#   patched May 2026. in CISA KEV since 2026-05-13. still working.
#   DIFFERENT flaw from CVE-2026-0322 (log 037), which needed an admin.
#   reporting does NOT list affected versions. check the vendor advisory.

# who: Qilin (Spikey Scorpius), INC (Tarnished Scorpius), Settra

# the chain
#   foothold -> bypass MFA for a VPN session
#   -> internal recon with dual-use RMM tools
#   -> lateral movement over RDP and SMB
#   -> credential harvesting, exfiltration, ransomware

# the escalation worth defending against specifically
#   VPN gateway -> vCenter management appliance
#   -> disable security controls on the ESXi hypervisors
#   -> dump credentials OFFLINE from a domain controller's virtual disk
#      file. in-guest EDR sees NOTHING, because in the guest nothing
#      happened. domain-wide credential theft, no in-guest detection.
#   also chained Veeam CVE-2023-27532 to reach backup infrastructure.

# so: treat vCenter and ESXi as tier-0. segment the management network
# from the VPN gateway. alert on VMDK/VMX access and datastore browsing.

7. OVHcloud CLI: rotate from a different machine

The window is narrow and exact, so the first question is whether you touched it at all during those 94 minutes. If you did, the rotation has to happen from a machine you are not worried about.

# scope
#   OVHcloud CLI releases v0.11.0 .. v0.15.0, ARCHIVES replaced
#   window: 2026-10-19 12:47 .. 14:21 UTC  (up to 94 minutes)
#   tag, source code and build pipeline were NOT touched
#   exposed: install script, manual download, unpinned CI, the CLI's own
#            upgrade command, on macOS and Linux

# NOT affected, and here is why each one held
#   Homebrew        the cask PINNED the original file hashes
#   from source     the tag was unchanged
#   go install      same
#   Docker          image had not been rebuilt in the window
#   installed before the window and did not update

# root cause, per OVHcloud
#   GitHub release immutability was NOT enabled, so a user with write
#   access could replace files on a published release, no CI in the way.
#   now enabled.

# remediation
#   rotate EVERY secret readable from a machine that may have run a
#   swapped build, and do it FROM A DIFFERENT MACHINE
#   remove the binary, install the immutable v0.16.0

# unknown: how creds were taken, what the binary read, where it sent
# data, how many copies were downloaded. no sample was preserved.

9. FortiSIEM: a public proof of concept is a countdown

Patched on 13 October, exploit code published on 20 October, and the Plex timeline from yesterday is the reason not to wait. The interim measure is network restriction, which is reasonable practice regardless.

# CVE-2026-106173   FortiSIEM   Fortinet rates 9.4
#   unauthenticated path traversal in the phQueryMaster gRPC service
#   on TCP 27918 -> arbitrary file write -> remote code execution
#   patched 2026-10-13, FG-IR-26-180
#   Horizon3.ai write-up + PoC published 2026-10-20
#   NO confirmed in-the-wild exploitation. not in KEV yet.

# fix
#   upgrade to the patched releases

# interim, and worth doing permanently
#   restrict TCP 27918 to trusted management networks only

# the precedent is one log old:
#   Plex details public 2026-10-16 -> attacks within about a day.

The closing argument: the short window is the strategy

Three separate supply chain attacks in one month, and the thing they have in common is not the technique. It is how briefly each one was available.

# attack                                      window
AOMEI poisoned updates        (log 039)      5 to 10 minutes at a time
Rank Math backdoored plugin   (log 041)      11 hours
OVHcloud swapped CLI builds   (log 042)      94 minutes

That brevity is strategy, not sloppiness. A backdoor that sits on a download page forever gets found, reported and analysed. One that is available for ninety minutes catches whoever happened to run an update during that hour and then vanishes. And it leaves the vendor's download page serving clean files by the time the victim goes to check, which is why the AOMEI case produced real detections that analysts kept dismissing: every verification came back clean, because by then it was clean.

That breaks the standard advice in a specific way. The advice was always download from the official source. All three of these were the official source. The vendor's own site, the vendor's own GitHub releases, the vendor's own update servers. Not a mirror, not a typosquat, not a search result. Reputation did not help, because the reputation was accurate and the file still was not.

What actually worked was pinning and verification, and you can see it in item seven with unusual clarity. Homebrew users were not more careful than anybody else. Their package manager compared a hash against one recorded before the attack, the comparison failed, and the install stopped. No judgement, no vigilance, no awareness that anything was happening. The same holds for the people who built from source against an unchanged tag, and for the Docker users whose image predated the window. Every single one of those is a machine checking a value, not a person making a good decision.

So the practical shape of the answer is pinned hashes, immutable releases and signature verification, applied by default rather than when something feels wrong. Pin dependency versions and their hashes in continuous integration instead of pulling latest. Turn on release immutability where the platform offers it, which OVHcloud did only after this. Verify signatures as a build step that fails, not as a thing you do manually when suspicious. A ninety minute window is unbeatable by attention and trivially caught by a hash comparison that costs nothing and runs every time.

Related: the patch was ten weeks old when the attacks started, where the Rank Math window and the Plex and Siemens items begin, four of these seven are somebody else's system failing into yours, and seven of these ten will never show up in a vulnerability feed, where the AOMEI update server story starts.

Sources

Primary advisories and first hand reporting, so you can check any figure or claim here against the people who published it.