DEV Community: yutianle

A user namespace maps container root to something that is not root, and the default keeps changing under you

yutianle — Mon, 26 Oct 2026 02:40:27 +0000

A user namespace maps container root to something that is not root, and the default keeps changing under you

Container isolation has always depended on a kernel feature doing more work than the marketing implied. Namespaces decide what a process can see; control groups decide how much resource it gets; capabilities decide which privileged operations remain. None of those changes what user ID the process runs as on the host. A user namespace is the mechanism that does, and its availability is a configuration decision most teams never make on purpose.

What the namespace maps

When a process creates a user namespace, it gets a full set of user and group IDs inside that namespace, mapped to a range of IDs outside. The process can be root inside, with UID 0, while the kernel records its real identity on the host as an unprivileged number in a subordinate range. Capabilities held inside the namespace apply to resources owned by that namespace, not to resources owned by the host's root.
That mapping is why the feature exists. It allows a container to run services that expect root without granting the host privileges those services never needed. The kernel documentation for user namespaces describes the mapping files and the subordinate ID ranges that make it work.
Two details matter for security review. The first is that the mapping is per-namespace and set at creation. A process cannot widen its own mapping afterwards, so the boundary is decided before the workload starts. The second is that the feature is recursive in a limited way: a process with the right privileges inside a namespace can create further namespaces, which is how nested containers work and also how some container escapes have been constructed.

Where the default sits

On many Linux distributions the ability for an unprivileged user to create a user namespace is controlled by the kernel.unprivileged_userns_clone sysctl or, on newer kernels, by an AppArmor restriction. The kernel's own documentation for kernel.unprivileged_userns_clone notes that it was added by distributions as a patch and that it controls whether unprivileged users can create user namespaces.
That single setting changes the threat model in both directions. Disabling unprivileged user namespaces removes a class of kernel privilege-escalation exploits that rely on the namespace to reach vulnerable code paths with elevated capabilities inside the namespace. Enabling it is required for rootless containers, for many sandboxing tools, and for browser sandboxes on Linux.
The container runtime adds a second layer. Docker's userns-remap option makes the daemon start containers inside a user namespace with a remapped root, so a process that believes it is root inside the container is an unprivileged host user. Podman and rootless modes of other runtimes use the same underlying mechanism by default. When the runtime does not remap, the container's root is the host's root, and the isolation is whatever the other namespaces and the capability set provide.

Why this keeps being a finding

The reason user namespaces appear in so many hardening discussions is that the same feature serves two goals that pull in opposite directions. Isolation wants more namespace layers and fewer host privileges. Compatibility wants containers that behave like small virtual machines, with root doing root things.
Organisations resolve the tension differently by workload. A build system that runs untrusted code benefits from rootless containers and remapped IDs. A database container on a dedicated host may reasonably run without remapping, because the operational complexity of file ownership across the mapping is real and the host is not multi-tenant.
What does not work is leaving the decision unstated. A host that permits unprivileged user namespaces while also running a container runtime that does not remap has enabled the feature's attack surface without collecting its benefit. That combination shows up in audits more often than either choice made deliberately.

A short review sequence

Determine whether unprivileged user namespace creation is permitted, and record the setting with its reason.
Determine whether the container runtime remaps user IDs, and for which workloads.
Inventory containers that run as root with the host root mapping; those are the ones where a kernel bug becomes a host compromise.
Map file ownership implications before enabling remapping on an existing host, since a remapped container cannot write files owned by the original root.
Revisit the decision when the kernel or runtime changes, because both sides of the trade have moved in recent releases.

References

Linux user namespaces manual page: https://man7.org/linux/man-pages/man7/user_namespaces.7.html
Kernel documentation, unprivileged user namespaces: https://docs.kernel.org/admin-guide/sysctl/user.html
Docker userns-remap documentation: https://docs.docker.com/engine/security/userns-remap/
Docker Engine security overview: https://docs.docker.com/engine/security/

IPFire: one application fingerprint, 44 page titles, and 998,984 body matches for a firewall

yutianle — Sun, 25 Oct 2026 23:41:06 +0000

IPFire: one application fingerprint, 44 page titles, and 998,984 body matches for a firewall

A firewall is the one device on a network whose management interface is more sensitive than the traffic it forwards. Its configuration describes the boundary itself: which hosts are allowed out, which services are allowed in, what the VPN terminates, and where the logs go. IPFire is an open-source firewall distribution aimed at exactly that role, with a web-based administration console. ZoomEye measurements taken on 26 October 2026 show a footprint where every count says something different about the same product.

The four observations

All queries ran against ZoomEye with sub_type="all" and pagesize=1, so each total describes matched assets rather than retrieved records.
| Query | Matches |
| --- | ---: |
| app="IPFire" | 1 |
| title="IPFire" | 44 |
| http.body="IPFire" | 998,984 |
| port=444 | 4,729,989 |
Four queries, four numbers spanning six orders of magnitude. The explanation is not that the product is more or less popular than the other measurements in this series. It is that each field measures a different thing, and for a firewall distribution three of them measure noise.

Reading each number for what it is

The fingerprint count of one is the tightest statement available: ZoomEye's fingerprint set contains a single rule that matched a single asset. A fingerprint requires a recognisable response shape, and a firewall console that demands authentication before rendering anything distinctive has little shape to match. One match means the rule exists and almost nothing satisfies it — not that one firewall exists.
The title count of 44 is the most useful figure. A page whose heading names the product is a page the product served. Forty-four such pages across the index describes a population that is deliberately small, which is what a firewall's configuration should look like: a device on a private network, reached from an administrative segment, not answering strangers.
The body count of 998,984 is the clearest example of name ambiguity in this series. "IPFire" appears in documentation mirrors, in comparison articles, in package indexes, in forum threads, and in any page that discusses open-source firewall options. A body match records that a word occurred, and one word occurrence has essentially no evidentiary value for exposure.
The port count of 4,729,989 is the same trap in numeric form. Port 444 carries HTTPS traffic for a long list of unrelated services, and a bare port query returns every one of them.

Why the console matters more than the perimeter

For a perimeter device, the usual exposure discussion gets inverted. An attacker probing a firewall from outside meets a packet filter, and the filter is doing the job it was configured to do. The interesting question is what happens when someone reaches the management console, because that interface changes the filter.
A console session can add a port forward, open a rule, disable a logging category, or export the configuration. Each of those is a legitimate administrative action taken by the wrong person, and the resulting state is indistinguishable from a deliberate change until somebody compares it against an expectation.
IPFire's documentation places the web interface on the firewall itself, with user accounts and an admin role. The security-relevant properties are the ones that hold for any such appliance: whether the console is reachable beyond the administrative network, whether the accounts are per-person or shared, and whether configuration changes are logged with a source identity.

The pattern worth naming

Across this measurement series, commodity network appliances show a consistent shape. Fingerprints are nearly empty because the login page is generic. Title counts are small because the device is not meant to be public. Body counts are enormous because the product name is a term of art in its own documentation.
An analyst who reports the largest number in that pattern has reported the least information. The defensible reading of the IPFire measurement is that 44 pages name the product in their heading, and that this is the population worth thinking about — not 998,984.

Controls that fit an appliance

Keep the management interface off the untrusted interface entirely. This is a rule the device can enforce, and the enforcement is what the configuration review should confirm rather than assume.
Use individual administrator accounts rather than a shared credential. A shared console password is a shared identity, and every configuration change in the audit log attributes to the same account.
Export and diff the configuration on a schedule. An appliance's rule set is small, textual, and version-controllable; a weekly diff answers the question "what changed" without reading logs.
Send logs off the device. A firewall that stores its own logs loses them in the incident that matters most, and the export destination is itself a configuration decision worth reviewing.
Keep the appliance current. The distribution includes packages beyond the firewall core, and each of them is a component with its own advisory history.

What the counts do not say

Nothing in these four numbers establishes that any firewall is misconfigured, that any console is reachable without authentication, or that a specific version is in use. They describe a page heading, a fingerprint rule, a word in a response, and the popularity of a port number.
The honest summary is short. On 26 October 2026, ZoomEye matched one asset against its IPFire fingerprint and 44 pages titled IPFire, while 998,984 responses contained the name and 4,729,989 hosts answered on port 444. The first two numbers describe the product. The last two describe the internet's vocabulary.

References

IPFire documentation: https://www.ipfire.org/docs
IPFire wiki: https://wiki.ipfire.org/
ZoomEye search platform: https://www.zoomeye.ai/

Measurement note

Queries: app="IPFire", title="IPFire", http.body="IPFire", port=444. Executed 26 October 2026, sub_type="all", pagesize=1, global scope. Counts describe matching assets, not confirmed vulnerabilities or exploitation.

Parsing Is the Attack Surface: Lessons From NSD and CVE-2026-101339

yutianle — Sun, 25 Oct 2026 20:40:23 +0000

Parsing Is the Attack Surface: Lessons From NSD and CVE-2026-101339

Every input format an internet-facing daemon accepts is a piece of attack surface, and the more obscure the format, the longer defects survive. The NSD update released on 14 October 2026 makes that argument concretely: four stack overwrites, all in the same zone file parser, found and fixed together.

The four defects

CVE-2026-101339 leads the set. A HIP resource record with RDATA filled near or at its limit, followed by a Rendezvous server dname, causes an out-of-bounds stack write of up to 191 bytes of attacker-controlled data. NLnet Labs describes the possible result as arbitrary command execution.

CVE-2026-101341 covers records built from string sequences, naming TXT, NINFO, SPF, AVC, RESINFO and WALLET. Text tokens under 32 bytes are not checked against the space reserved for RDATA, so the write can be arbitrarily sized and can overwrite a callback function pointer invoked immediately after parsing.

CVE-2026-101338 concerns SVCB and HTTPS records. When the wire-format RDATA is filled to capacity, an additional ECH parameter carries the parser past the boundary, and the base64 decoder writes attacker data with no size limit.

CVE-2026-101337 involves base64 presentation formatting. Splitting base64 into pieces of three characters or fewer causes the token size to be computed as zero, opening a window of up to 64 KB.

All four affect NSD 4.10.0 through 4.15.2 and are fixed in 4.15.3. CVSS v4.0 scores are 8.7 for each. No public proof of concept and no exploitation in the wild were reported.

The common root cause

Look past the record types and one pattern appears: the parser trusted a length it calculated itself. Text tokens, ECH parameters, base64 chunk sizes, and HIP rendezvous names all pass through code that derives a size and then writes without re-verifying the destination.

The four fixes address a class of error. Where one instance of it exists in a parser, others usually do, and the four fixes here look like the result of a systematic review of the same code area rather than four independent discoveries.

Three researchers are credited across the advisories, including Qifan Zhang of Palo Alto Networks, Alwaleed Ashi of LXR, and Gaurang Maheta, which fits that theory: multiple reviewers sweeping the same parser.

Why the file path matters more than the wire

The advisories state that zone files written by NSD itself, including for secondary zones, will not be formatted in the triggering way. The file must be handed to NSD directly.

For a defender this is the single most useful sentence in the release. It eliminates the entire population of pure secondary servers from the direct risk set, and it focuses attention on provisioning. Any pipeline that converts outside input into a zone file belongs on the review list. So does any environment where a customer, partner, or automated feed can influence zone contents.

Where the exposed population sits

ZoomEye returned 116,266 assets for the NSD product fingerprint app="NSD" at 2026-10-25T20:15:54Z.

Those are internet-visible services carrying the fingerprint. The number does not encode version, role, or ingestion policy, which are the three attributes that determine real risk. An identifier-scoped query for CVE-2026-101341 returned zero, illustrating how limited CVE-level index coverage is for a fresh advisory.

Combine the fingerprint measurement with your own configuration records. The intersection is your actual work list.

Fix and follow-up

Move to NSD 4.15.3 or newer. For source-based installs that cannot, each advisory provides a diff against 4.15.2, applied with patch -p1 < patch_CVE-2026-101339.diff in the source directory and then make install. Applying one diff out of four is not a fix.

After the upgrade, restart the daemon and verify the running version, because the parser executes in memory.

Then treat parsing as a standing review topic. Enumerate every format your internet-facing services accept from outside parties, and ask for each whether length handling has been tested against deliberately malformed input. The NSD release shows the answer is often no until someone looks.

References

NLnet Labs advisory for CVE-2026-101339: https://nlnetlabs.nl/downloads/nsd/CVE-2026-101339.txt
NLnet Labs advisory for CVE-2026-101341: https://nlnetlabs.nl/downloads/nsd/CVE-2026-101341.txt
NLnet Labs advisory for CVE-2026-101338: https://nlnetlabs.nl/downloads/nsd/CVE-2026-101338.txt
NLnet Labs advisory for CVE-2026-101337: https://nlnetlabs.nl/downloads/nsd/CVE-2026-101337.txt
NSD 4.15.3 release tarball: https://nlnetlabs.nl/downloads/nsd/nsd-4.15.3.tar.gz
SecurityOnline summary: https://securityonline.info/nsd-stack-overwrite-vulnerability-patched/

Port 873 lists its modules before it asks who you are

yutianle — Sun, 25 Oct 2026 17:42:26 +0000

Port 873 lists its modules before it asks who you are

ZoomEye returns 1,689,755 results for port="873", the TCP port the rsync daemon listens on. The daemon is a different program from the rsync client, and the difference is the point: the client is an authenticated file transfer over SSH, and the daemon is a standalone service that speaks the rsync protocol directly on the network.

The module list is the invitation

An rsync daemon is configured with modules. Each module names a path on disk and a set of options, and the daemon answers a request for the module list before it asks for a credential. That behaviour is documented in rsyncd.conf(5), and it means an unauthenticated client can enumerate the exports the way an SMB client enumerates shares.
The list is not a file disclosure on its own. It is a map. A module named backup, www, home or dbdump tells an attacker which path is worth authenticating against, and the answer to whether authentication is required is in the same configuration file.

Where the daemon is weaker than the client

Three options decide how much a module exposes. read only = true prevents writes, and it is the default for a reason. auth users plus secrets file requires a username and password for the module. hosts allow restricts the source addresses that may connect at all.
A module without those three is a directory published to anyone who can reach the port. The rsync documentation also covers use chroot and munge symlinks, which matter when a module is writable: a writable export that follows symlinks out of the module root is a path traversal primitive, and the munge symlinks option exists to blunt it.
The measurement cannot tell which of the 1,689,755 hosts is in which state. A port match is a listener, not a configuration. What it does establish is the size of the population where the question is worth asking.

A check that answers the question first

Ask the daemon for its module list, then ask a specific behaviour question about the same module:

rsync rsync://<host>/
rsync rsync://<host>/<module>/
rsync -av --dry-run rsync://<host>/<module>/ /tmp/module-listing/

The first command is the enumeration. The second shows whether the module requires a password. The third is a dry run that reports what a read would copy without copying it, and a module that returns a tree for that command is readable without a credential.
On the defender side, the configuration is auditable with the same file the daemon reads. A module that needs to accept writes from another host should have hosts allow scoped to that host, auth users set, and a secrets file with restrictive permissions. A module that has none of those three should be reviewed against the question of who was supposed to reach it.

What the number does not say

1,689,755 is a count of hosts that answered on the port on 2026-10-25 with sub_type=all. It is not a count of open exports, and the rsync daemon is also used on internal networks where a public listener is exactly the design. The finding is the fraction of that population whose module list is readable and whose exports are writable, and that fraction requires a second measurement the index cannot make.

References

rsync(1), Linux manual page: https://man7.org/linux/man-pages/man1/rsync.1.html
rsyncd.conf(5), Linux manual page: https://man7.org/linux/man-pages/man5/rsyncd.conf.5.html
ZoomEye, query executed 2026-10-25 with sub_type=all: https://www.zoomeye.ai/

BlockStrap triage: why a CVSS 10.0 Magento flaw got a priority 2 rating, and what to do about it

yutianle — Sun, 25 Oct 2026 14:43:17 +0000

BlockStrap triage: why a CVSS 10.0 Magento flaw got a priority 2 rating, and what to do about it

Two ratings, two questions

Adobe assigns two labels to a Magento security issue. CVSS describes severity. Priority describes scheduling, and in Adobe's Magento practice priority 1 is reserved for vulnerabilities the vendor knows are being exploited, which allows a shorter patch window. BlockStrap carries priority 2 and a 30-day window.
Sansec questions that split. The flaw, CVE-2026-103849, is scored 10.0 under CVSS 3.1 with the vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H and mapped to CWE-1336 by NVD. Sansec reproduced four routes to code execution within 24 hours of the patch and argues that an AI-assisted reverse-engineering effort shortens the distance between patch and exploit. Under Adobe's definition, the rating is consistent: no exploitation was known at publication, and Sansec reported no attacks on live stores when it published its analysis on 15 October 2026.
Both statements can be true. A triage decision has to pick which one governs.

What the rating does not say

Priority 2 does not mean low risk. It means the vendor's information at publication did not include exploitation. The definition creates an incentive to wait for evidence of attacks, and by then the flaw is in use.
The precedent inside the same engine is recent. StyleSmuggler, CVE-2026-75650, moved from a priority 1 hotfix in September 2026 to mass exploitation in three days, using the September hotfix VULN-39341 as its fix. Sansec describes BlockStrap as similar in complexity.

The preconditions that matter for triage

Exploitation needs a pre-authentication input path into the email template pipeline, such as guest checkout and a failed payment, and a deployable block gadget for the execution step. The public validation lab documents the carrier and the stock directive-injection primitive, and states that it did not find a compatible command execution gadget in the subset of Magento Open Source 2.4.9 it reviewed. That is a statement about one tree, not about the extension population of a real store.
A store with a large extension set has a larger gadget surface than the lab's tree. A store with no custom modules has less. That difference belongs in the triage, not in the vendor rating.

Affected range in one place

Adobe affects Adobe Commerce up to 2.4.9-2026-sep, with the earlier 2026-sep releases for 2.4.8, 2.4.7, 2.4.6, 2.4.5 and 2.4.4 also listed, and Adobe Commerce B2B up to 1.5.3-2026-sep. Magento Open Source is affected in 2.4.9-2026-sep, 2.4.8-2026-sep and 2.4.7-2026-sep. Mage-OS is affected up to 3.5.0 and fixed in 3.6.0. The 2026-oct releases and 2.4.10-alpha1 are unaffected.
Open Source stores on 2.4.4, 2.4.5 and 2.4.6 have no public Adobe patch. The vendor patches for those branches need an Adobe Commerce license. Happy Horizon published backports for 2.4.4-p18 through 2.4.9, and Sansec states it gives no warranty for them while recommending an upgrade to 2.4.7-p10 or later.

A triage rule that holds

Patch the supported branches inside the vendor window or shorter. For unsupported branches, decide explicitly between an upgrade project, a reviewed backport, and a compensating HTTP-layer control, and write the decision down with an expiry date.
Sequence the work: VULN-39341 first, then the October release or isolated patch, because the October patch does not carry the hotfix and Adobe's registry does not require it. Verify in code with resolveDeferredDirectives in the template filter, and with vendor/bin/magento-patches -n status for the hotfix. On 2.4.8-p5, check QUOTED_LOCAL_PART_PATTERN in vendor/magento/framework/Validator/EmailAddress.php for the corrected patch file.
Then check for execution. A flaw with a public patch and a working primitive has a window measured in days, whatever the scheduling label says.

Sources

Four Plex Media Server flaws and what their CVSS vectors say about patch order

yutianle — Sun, 25 Oct 2026 11:41:56 +0000

Four Plex Media Server flaws and what their CVSS vectors say about patch order

Plex Media Server before 1.43.3.10861 is affected by a set of four related flaws that the CNA published separately: CVE-2026-96652, CVE-2026-96654, CVE-2026-96655 and CVE-2026-96656. The identifiers are not four copies of one bug. Each record names a different endpoint or subsystem and each carries its own severity, which gives administrators a defensible order for patching even when all four share a single fixed version.

Vulnerability overview

CVE-2026-96652 is a SSRF in the timeline handler with CVSS v3.1 score 4.3. CVE-2026-96654 is a URL injection problem in searchOne with score 6.5 and CWE-84. CVE-2026-96655 is an arbitrary-host SSRF through the /video/:/transcode/universal path parameter with score 4.3. CVE-2026-96656 is an arbitrary file write involving TranscoderH264Options with score 7.2 and CWE-73.

Mechanism and exploitation conditions

The timeline issue lets an attacker put a complete URL into the protocol parameter and make the server POST to that destination using any X-Plex-Token value. The searchOne issue fails to neutralize URL values, which the record says allows calling other plugins' functions with attacker-supplied parameters; its vector lists no privileges required, so the entry point is unauthenticated. The transcode issue accepts arbitrary internal or external addresses in a path parameter for authenticated users. The file write issue requires an admin-level account and appends the TranscoderH264Options preference verbatim to the x264 option string on every transcode.

Impact

Confidentiality is the main loss in the two SSRF records, both with C:L and no integrity or availability impact. The URL injection record adds low integrity impact. The file write record is the heaviest of the four at C:H/I:H/A:H, because the description says written files may be executed on load: at startup the server runs .so files without signature, execute-bit or symbol checks. That is the difference between reading internal responses and running code in the server's context.

Affected products and scope

All four records cover Plex Media Server below 1.43.3.10861 and mark that build unaffected. The privileges required differ sharply: none for CVE-2026-96654, low for CVE-2026-96652 and CVE-2026-96655, high for CVE-2026-96656. The unauthenticated entry point deserves attention even where the admin-only flaw has the higher score.

Exposure context

A ZoomEye query for app="Plex Media Server" returned 507,974 matching assets during preparation, which shows how widely the product is deployed on reachable addresses. The same data does not tell you which of those servers run a build below the fixed version, and the CVE filter for CVE-2026-96652 returned no matches. Exposure figures describe the product surface, not the population of vulnerable hosts.

Remediation and mitigations

Move to 1.43.3.10861 or later, which resolves all four identifiers. While scheduling the upgrade, reduce reachability of the server's HTTP interface and of the transcode endpoint, and cut down on accounts with admin rights, since the file write path depends on that level of access. After the upgrade, check the transcode preferences for unexpected values and confirm that no unsigned shared objects sit in the plugin directories.

References

CVE-2026-96652, https://www.cve.org/CVERecord?id=CVE-2026-96652
CVE-2026-96654, https://www.cve.org/CVERecord?id=CVE-2026-96654
CVE-2026-96655, https://www.cve.org/CVERecord?id=CVE-2026-96655
CVE-2026-96656, https://www.cve.org/CVERecord?id=CVE-2026-96656
CISA CSAF advisory va-26-266-01, https://raw.githubusercontent.com/cisagov/CSAF/develop/csaf_files/IT/white/2026/va-26-266-01.json

PAN-OS CVE-2026-0321 attack chain: what an outsider gains and leaves behind

yutianle — Sun, 25 Oct 2026 08:42:15 +0000

PAN-OS CVE-2026-0321 attack chain: what an outsider gains and leaves behind

Strip the advisory language and CVE-2026-0321 is a straightforward proposition. An outsider with a network path to a PAN-OS dataplane interface can make a firewall stop forwarding, and can make it stay stopped.

The three prerequisites

The CVE Record, published 14 October 2026, sets the conditions precisely. The attacker needs network access to a dataplane interface, crafted traffic that reaches the network services handling it, and the willingness to repeat the attempt.
That is the whole list. No administrator session, no stolen token, no management-plane foothold. CVSS 4.0 encodes it as AV:N/AC:L/AT:N/PR:N/UI:N/VA:H, a MEDIUM 6.6 that reads like a low-priority bug until you notice the two fields that matter: PR:N and VA:H.

Why repetition is the interesting part

A single crafted burst degrades availability. The record states that repeated attempts push the device into maintenance mode, a state normally entered deliberately during recovery work.
For an attacker, repetition is free. For the defender, repetition converts a transient event into a manual intervention that may need console access, a support case and a physical or out-of-band path. That asymmetry is the actual risk, not the one-shot outage.

What the attacker does not get

This is not an initial-access vulnerability. The record attributes no confidentiality or integrity impact, and the version scope excludes Cloud NGFW and Panorama. There is no published claim of data theft, credential capture or configuration modification.
Saying so plainly matters, because it changes the response. Teams should not launch a compromise investigation based on this CVE alone. They should patch availability, then keep their normal intrusion detection running for unrelated reasons.

Detection signals worth watching

The vendor names no workaround and provides only limited coverage through Threat ID 510038 from Applications and Threats content 9158-10284 onward, which requires SSL Decryption. That leaves telemetry as the practical detection surface.
Useful signals include a sudden loss of dataplane forwarding without a matching configuration change, repeated entries into maintenance mode clustered in time, and interface error counters or drop rates deviating from a device's baseline. Correlate those with upstream network telemetry: if flows to a firewall's public address spike while the device stops forwarding, you have a shape worth investigating.

Why this matters for internet-facing firewalls

Perimeter firewalls sit on the interface the attacker needs. That is not an oversight by the vendor; it is the product's job. The mitigation is not to hide the dataplane but to shorten the window in which an unpatched build is answering.
Fixed releases exist across 10.2, 11.1, 11.2, 12.1 and 12.2 branches, with the newest fix per branch listed in the record. Cloud NGFW and Panorama are unaffected, which means a mixed estate needs a per-device plan rather than one broad change.

The honest limits of exposure data

A ZoomEye query for app="Palo Alto Networks" returned 22,599 matching assets on 22 October 2026, and vul.cve="CVE-2026-0321" returned 0. The first number sizes a product population. The second shows that CVE attribution had not reached indexed assets days after publication.
Neither number identifies a vulnerable device. Version and interface exposure live inside your own management plane, and that is where an upgrade decision has to be made.

Detection engineering starting point

Write down what normal looks like before the next incident: baseline forwarding rates, normal maintenance-mode entries, expected error counters. Then alert on deviation. A vulnerability that offers no lateral movement still deserves a detection rule, because the outcome it produces, a silent perimeter, is exactly the condition other attackers prefer to work behind.

A Hunting Sheet for Refrigeration Controllers After a Cold-Chain Attack

yutianle — Sun, 25 Oct 2026 05:40:38 +0000

A Hunting Sheet for Refrigeration Controllers After a Cold-Chain Attack

When an attack on supermarket refrigeration becomes public, the organisations most affected are often not the ones named. A retail chain in another country runs the same controller class, the same monitoring gap, and the same assumption that a control panel has no reason to face the internet. The work that follows is a hunt, and a hunt needs a sheet rather than a narrative.
This sheet is built from the 11 October 2026 incident in France, where cooling systems at hundreds of supermarkets were disrupted and Danfoss confirmed its equipment was targeted.

Step 1: Establish whether the asset class is yours

Before any log query, confirm that you own the equipment being discussed. Danfoss named the AK-SM800 and AK-SC355, which no longer receive security updates, and the AK-SM800A, which does. StoreView is the control panel in front of those controllers. If none of those names appear in your asset register, the rest of the sheet does not apply, and the correct output is a note for the procurement team rather than an investigation.
If they do appear, the asset register is already the most valuable evidence you hold, because it links a serial number to a site, a contract and a maintenance provider.

Step 2: Measure external reachability before touching logs

An incident hunt that starts in the SIEM starts in the wrong place when the question is whether a device is exposed. The external view is faster and independent, and it produces a number that can be re-checked after a change.
The ZoomEye header query run on 22 October 2026 gives the shape of that measurement:
| Query | Result |
| --- | --- |
| http.header="Danfoss" | 260 |
| http.header="Danfoss" && port="80" | 120 |
| http.header="Danfoss" && port="443" | 132 |
| http.header="Danfoss" && is_ipv4=true | 138 |
| http.header="Danfoss" && is_domain=true | 122 |
| http.header="Danfoss" && country="NL" | 54 |
| http.header="Danfoss" && country="US" | 28 |
| http.header="Danfoss" && country="DE" | 25 |
| http.header="Danfoss" && country="FR" | 1 |
The count is not a vulnerability count and not a compromise count. It answers one question: does a public address respond with this vendor string? Record the query, the date and the count, because that record becomes the baseline against which every later claim is checked.
A country filter narrows the set but does not assign ownership. Fifty-four Dutch assets are not fifty-four Dutch operators, and the presence of a panel in a country does not mean a local entity controls it.

Step 3: Build the log queries the attack would leave

External exposure tells you where to look. The incident tells you what a compromise would have left behind. Danfoss did not confirm the initial access vector, so the hunt has to cover several plausible paths without asserting one.
The log questions worth answering, in order of evidentiary value:

Did the controller panel accept a connection from an address outside the operator's known ranges? Start with the panel's own access log if it has one, then the firewall in front of it.
Did the panel's firmware version change, or did the device reboot outside a maintenance window? A reboot before the incident is a weak signal; a reboot combined with an unusual source address is a strong one.
Did temperature telemetry diverge from the physical record? The Claroty demonstration showed that CVE-2025-41450 and CVE-2025-41451 could be chained to disable cooling while falsifying readings. A refrigeration log that reports normal temperature during a known disruption is the single most interesting artefact in this incident class.
Did anyone use remote support access around the incident window? Third-party maintenance is a legitimate and frequent path into these panels, and it is also the path least likely to be reviewed.

Step 4: Separate what you know from what you inferred

A hunt sheet is only useful if it keeps the epistemic layers apart. In this incident the layers are:
| Layer | Status |
| --- | --- |
| Attack on French supermarket cooling | Confirmed by Danfoss |
| Affected models and firmware state | Stated by Danfoss |
| Chained RCE against two CVEs | Demonstrated by Claroty |
| Initial access vector | Not confirmed |
| Mass disconnection as the response | Inferred by Censys from version-category shrinkage |
An investigation that promotes the last two rows to fact will produce a report nobody can defend. An investigation that keeps them as inferences can still act on them, because disconnection is cheap and the version question is answerable internally.

Step 5: Close with evidence, not intent

The final row of any hunt sheet is the one most often skipped. Three artefacts close a refrigeration hunt credibly:

A dated external measurement before and after any change, using the same query string.
A firmware version read from the device, matched against the 4.3.1 boundary that covers all three 2025 CVEs.
A named owner for each panel, with a documented decision to keep it internet-facing or not. ZoomEye contributes to the first artefact and nothing else. It cannot read firmware, cannot see a private-range panel and cannot confirm that a restored device was patched. A sheet that says so is more useful than one that implies a search engine closed the case.

The sheet in one line

Measure reachability from outside, then read firmware from the device, then reconcile the two against a named owner. Everything else in this incident, including the 71% drop that followed, is context for that sequence.

References

Infosecurity Magazine, "France: Internet-Exposed Danfoss Controllers Drop 71% After Cyber-Attack", https://www.infosecurity-magazine.com/news/france-expose-danfoss-controllers/
Censys, "Frostbitten in France: A Danfoss StoreView internet exposure report", https://censys.com/blog/frostbitten-in-france-a-danfoss-storeview-internet-exposure-report/
ZoomEye search syntax baseline, https://zoomeye.ai/agent.md

A dormant payload in a comment: the second-order flaw in Duplicator CVE-2026-82814

yutianle — Sun, 25 Oct 2026 02:42:48 +0000

A dormant payload in a comment: the second-order flaw in Duplicator CVE-2026-82814

Wordfence researchers found an unauthenticated PHP object injection flaw in the Duplicator WordPress plugin and in Duplicator Pro. The flaw is tracked as CVE-2026-82814 and scored 8.8 under CVSSv3. What makes it worth studying is the delay. The attacker plants a value that does nothing until an administrator performs a routine migration.

The two-stage mechanism

The advisory describes a second-order vulnerability. An unauthenticated attacker places a malicious value in an ordinary WordPress comment, where it remains dormant. If an administrator later creates a Duplicator package containing that comment and uses the package to migrate the site, the standalone installer treats the stored value as a PHP object and activates it.
The first stage is a form submission. An attacker posts a base64-encoded PHP object to wp-comments-post.php without needing an account. Moderation does not help, because WordPress stores pending comments in the database, and the value sits in the same table either way.
The second stage is deserialisation during migration. The DUPX_UpdateEngine::unserializeTest() function decodes base64 strings and passes them to PHP's native unserialize() without restricting allowed classes. That missing control turns stored text into a live object.
Wordfence researchers found the bug on 30 August 2026 using their AI-assisted system, Wordfence Argus, during a WordPress 7.1 assessment. No public proof-of-concept exploit code has been published and no active exploitation has been confirmed.

The two impacts, split by edition

The path after deserialisation differs between the free and paid editions, and that difference is operationally significant because the response differs too.
In Duplicator Free, the installer pairs the DbUserMode class with an older Requests library iterator to pass attacker-controlled arguments to call_user_func(). The result is arbitrary operating-system command execution as the web-server user.
In Duplicator Pro, attackers abuse the Duplicator\Libs\Index\IndexList destructor to delete arbitrary files. Wordfence notes the specific consequence: deleting wp-config.php reopens the WordPress setup process, which can lead to site takeover and PHP code execution if the attacker reaches the setup process first and supplies a database they control.
Command execution is immediate. File deletion that reopens an installer is quieter and hands the attacker a second opportunity later.

Affected versions and the fix

Duplicator Free up to and including 1.5.17 is affected. Duplicator Pro up to and including 4.6.10 is affected. Both are fixed in 5.0.0 and later. The plugin reports more than one million active installations.
The vendor fix is specific: version 5.0.0 introduced SnapUtil::safeUnserialize(), which sets allowed_classes to false during deserialisation. That is the correct shape of the control, because it constrains which classes the parser may instantiate rather than trying to filter input strings.

The step that updating does not cover

Updating the plugin does not fix backup archives that were generated before the patch. If a package was created while a malicious comment was in the database, the payload travels inside the archive. Wordfence advises generating fresh packages with the patched release before performing any site migrations.
That advice implies a review step many site owners will skip. If a migration was performed in the recent past using an older package, the question is not whether the plugin is now patched but whether the installer that ran was the vulnerable one. The reporting does not state how long the dormant value persists before a migration picks it up, which means the exposure window is bounded only by archive retention.

Checks for a site running Duplicator

Confirm the plugin version. Anything below 5.0.0 is in range, and a pending update notice is not evidence of the installed version.
List backup archives with their creation dates. Any archive created before the upgrade to 5.0.0 should be treated as untrusted and replaced rather than reused.
If a migration ran on an older archive, look for consequences of both impacts: unexpected processes spawned by the web-server user, missing wp-config.php, and a setup wizard that became reachable again.
Review the comment table for values that do not look like prose, especially base64-shaped strings. Deletion is not sufficient on its own, because the value may already be inside an archive, but it prevents the next package from carrying it.

What the reporting does not establish

The reporting does not state whether the pending-comment path requires the site to accept comments at all, does not quantify how many installations were exposed, and does not describe whether any Duplicator archive in the wild has been used as a delivery container. The EPSS figure quoted is 0.5% for 30 days, which is a forecast rather than an observation. Site owners should treat the archive question as open until their own inventory answers it.

References

SecurityOnline, "Duplicator WordPress Plugin Patched for High-Severity PHP Object Injection Vulnerability", 22 October 2026: https://securityonline.info/duplicator-wordpress-plugin-php-object-injection/
Wordfence Threat Intelligence report on CVE-2026-82814 referenced in the reporting (discovery 30 August 2026).

Why manager:update_config should be treated as root, thanks to CVE-2026-74041

yutianle — Sat, 24 Oct 2026 23:43:42 +0000

Why manager:update_config should be treated as root, thanks to CVE-2026-74041

Permission models in security platforms often grant configuration rights generously. Administrators rotate rules, adjust logging and tune pipelines, so configuration access looks like an editing privilege. CVE-2026-74041 shows the gap between that intuition and reality in Wazuh Manager 4.14.3 through 4.14.7: a holder of manager:update_config can reach root command execution on the manager host.

INCIBE-CERT published the advisory as INCIBE-2026-753 on 16 October 2026 with a critical rating. The flaw is a case-handling mismatch between the ossec.conf validator and the wazuh-logcollector component. An upper-case LOG_FORMAT directive escapes remote command validation and executes as root when the service reloads.

The privilege escalation, stated plainly

Configuration write access is not supposed to be shell access. In this instance it is.

The account must be authenticated and hold manager:update_config. That is the only stated precondition besides the reload. There is no unauthenticated path, no network position requirement and no need to persuade a second party to act. Someone who can edit configuration can plant a directive and wait for the restart that operations will perform anyway.

What the permission actually governs

ossec.conf is not a cosmetic settings file. It directs collectors, defines what gets forwarded and contains directives with command semantics. Any component that turns configuration text into executed commands converts configuration authority into process authority.

The validator exists because someone recognised that risk. The bypass exists because the validator and the interpreter disagreed about a string. A control implemented in the wrong place produces an illusion of safety, which is worse than a documented absence of control because it discourages scrutiny.

Consequences for the platform

Root on a Wazuh Manager affects more than one host. The manager maintains the rule set, receives telemetry from agents and can dispatch active-response actions. Control of that process is control over the monitoring fabric. The advisory documents the root execution; it does not document observed post-exploitation behaviour, and readers should not assume intrusion reports that do not exist.

Redesigning the permission boundary

Three changes follow directly from the advisory.

First, classify manager:update_config as tier zero. Treat holders the way you treat holders of domain administration or hypervisor console access: named individual accounts, documented justification, periodic review and alerting on use.

Second, separate the ability to view configuration from the ability to commit it. Where the product allows it, route changes through a workflow with a second reviewer. An approved change brings its own audit trail.

Third, monitor reloads as privileged actions. A restart of the manager is the moment a configuration payload becomes executable. Logging who triggered it, and pairing that record with the configuration diff, gives incident responders a usable timeline.

Versions and fix

Product: Wazuh Manager.
Affected: 4.14.3 inclusive through 4.14.7.
Fixed: 4.14.8.
Advisory: INCIBE-2026-753, 16 October 2026.
CVE: CVE-2026-74041.

Upgrade to 4.14.8 or later. The permission review is worthwhile regardless, because the next configuration-to-code defect in any platform will lean on the same trust assumption.

Exposure reading

ZoomEye returned 18031 assets for app="Wazuh" and zero for vul.cve="CVE-2026-74041" when queried for this article. The first figure counts fingerprinted Wazuh services; the second counts indexed findings for this CVE. Neither measures the number of vulnerable installations, which only version inspection can establish.

Search link: https://www.zoomeye.ai/searchResult?q=YXBwPSJXYXp1aCI%3D

Sources

INCIBE-CERT, INCIBE-2026-753: https://www.incibe.es/incibe-cert/alerta-temprana/avisos/gestion-incorrecta-de-mayusculas-y-minusculas-en-wazuh-manager
ZoomEye query records, 2026-10-22: app="Wazuh" (18031); vul.cve="CVE-2026-74041" (0).

A Subdomain Field That Became a Credential Harvester: SAP Cloud SDK CVE-2026-89111

yutianle — Sat, 24 Oct 2026 20:45:44 +0000

A Subdomain Field That Became a Credential Harvester: SAP Cloud SDK CVE-2026-89111

SAP scores CVE-2026-89111 at 10.0. That is an unusual number for a server-side request forgery, and the reason is scope: the bug does not merely send a request to the wrong host, it hands the attacker the credentials needed to complete that request themselves. The affected package is the SAP Cloud SDK for Python, and the fix shipped in two parts, months apart, with a regression between them.

The mechanism

The SDK builds an OAuth2 token URL for the client credentials flow. Part of that URL comes from a caller-supplied value named tenant_subdomain, which the SDK substitutes into the URL by string replacement.

Whoever controls tenant_subdomain controls the destination host. When fetch_token runs, it sends grant_type, client_id and client_secret in the form body to whatever host that value points at. An attacker who can set the field to a host they operate receives the client secret directly, with no parsing trick required.

Those credentials buy a real access token from the legitimate endpoint. The token carries whatever permissions the original client held, and the documented Destination configuration stores third-party system credentials. The blast radius runs from one subdomain parameter to the credentials of every system that SDK integrated with.

Two fixes, and a window in between

The advisory lists affected versions below 0.45.2, with the fix in 0.45.2. According to the vendor, that is the whole story.

In practice it is not. Researchers tested each release and found that the module migration work in 0.53.0 reintroduced the flaw, which remained present through 0.55.0. Version 0.55.1 re-fixed it; the current release line is 0.58.5.

The per-version behaviour is reproducible. 0.45.0 and 0.45.1 send the secret to the attacker host, 0.45.2 blocks it, 0.53.0 and 0.55.0 send it again, and 0.55.1 and 0.58.5 block it. One test run against 0.53.0 captured two separate credential sets from a single request flow.

That gap is the finding worth carrying away. Anyone who patched to 0.45.2 and later upgraded to 0.53.0 for unrelated reasons became exploitable again, and no advisory said so. A version-range check driven by the vendor advisory alone would report those hosts as fixed.

Disclosure context

The issue was published at SAP Security Patch Day on 13 October 2026 alongside 19 other vulnerabilities: 4 critical, 3 high, and 4 that had been pre-published on GitHub. No in-the-wild exploitation has been reported.

Other items in the same batch matter for anyone tracking SAP exposure broadly. CVE-2026-89110 is a broken access control issue in NetWeaver Visual Composer. CVE-2026-89107 is code injection in S/4HANA. CVE-2026-89108 is a missing authorization check in Manufacturing Integration and Intelligence, scored between 9.9 and 9.1 depending on the source.

What to do

Compare the installed version against 0.45.2, 0.55.1 and 0.58.5, and treat anything in the 0.53.0 to 0.55.0 range as vulnerable regardless of what an advisory lookup reports.
If an upgrade cannot land yet, whitelist tenant_subdomain against the values your integrations actually use. It is a narrow control, but it addresses the injection point itself.
Rotate client secrets for any SDK integration that ran a version in either vulnerable range. Assume the secret was exposed.
Review what the affected client was authorized to reach. The token the attacker obtains is the client's token, so the question becomes what that client could read, and the Destination configuration is where to look.

The lesson that outlasts the CVE

Advisories describe the versions the maintainer knew about when the advisory was written. A regression introduced later, during a refactor, is invisible to an advisory-based scanner and to any team whose remediation reads as an instruction to upgrade past the listed version.

For a library that handles credentials, the durable control is a negative test in your own pipeline: point tenant_subdomain at a host you control, run the token fetch, and assert that no secret leaves. That test survives version changes, module migrations, and advisory text nobody has updated.

References

SAP Security Patch Day, 13 October 2026, SAP Note for CVE-2026-89111
GHSA-4mv3-jxxm-9cx2 (SAP Cloud SDK for Python, OAuth2 SSRF)

1,807 Gateways, 1,161 on 443, Zero CVE Matches: Scoping Cisco SEG Exposure

yutianle — Sat, 24 Oct 2026 17:41:06 +0000

1,807 Gateways, 1,161 on 443, Zero CVE Matches: Scoping Cisco SEG Exposure

CVE-2026-76519 has a CVSS of 9.8, a CISA KEV entry, and confirmed exploitation. In the ZoomEye index the CVE dork returns nothing. Both facts are true, and the distance between them is the methodological argument of this piece.

Context and method

Counts from the ZoomEye index, 23 October 2026, sub_type=all, pagesize=1, page 1. Fingerprint matches, not installations, and not statements about the Content Scanner Tools version.

Query	Total
`app="Cisco Secure Email Gateway"`	1,807
`app="Cisco Secure Email Gateway" && port=443`	1,161
`vul.cve="CVE-2026-76519"`	0

The application fingerprint finds 1,807 hosts. Scoping to 443 leaves 1,161, so 646 matches answer on a port other than 443. The CVE dork returns nothing at all, on a vulnerability that sits on the KEV list.

Why the CVE count is zero and the risk is not

vul.cve correlates identifiers against version data the index has already parsed. Vendors of email security appliances generally do not publish a version string on an unauthenticated page. Without a version there is nothing for the correlation to attach a CVE to, so a perfectly indexed host running a vulnerable Content Scanner Tools build produces no CVE match.

That is the general case rather than an exception. Appliance-style products hide their versions precisely because exposing them aids reconnaissance. The index cannot correlate what it cannot see, and a missing correlation is not a missing vulnerability.

For this CVE there is a second reason the vulnerable population is narrow: exposure requires File Reputation enabled and Content Scanner Tools older than 25.3.0.5525. A gateway without File Reputation enabled is not vulnerable, and it is also not distinguishable from a vulnerable one by any external query.

What the port split tells you

The 646 matches that do not answer on 443 are the interesting subset. Email gateways present management and mail interfaces differently, and a gateway whose management plane answers on a non-standard port has survived whatever firewall review was applied to 443.

The reverse reading holds too. Of the 1,161 on 443, some proportion sit behind a reverse proxy or load balancer that terminates TLS, so the index measures the proxy rather than the appliance. Neither number counts exploitable hosts.

Reading a mail gateway count in context

1,807 is small by the standards of this series. Set it against 419,779 n8n fingerprints or 5,623,921 MQTT services and it looks manageable. That comparison is the point: a mail gateway is a high-value target with a small internet population, which makes it the kind of asset where complete inventory is achievable and therefore hard to excuse skipping.

A scoped verification plan

Query both the app and the app-plus-port dorks against your own address space. Any host appearing in the first but not the second has its management plane somewhere a port-443 review would not have looked.
Do not rely on the CVE dork for appliances. Retrieve versions from the appliances themselves, and check both the AsyncOS build and the Content Scanner Tools build, because the exposure lives in the second.
Establish whether File Reputation is enabled. That single setting decides whether the CVE reaches the host at all.
If File Reputation must stay on and the scanner tools cannot be updated yet, remove untrusted senders' ability to reach the content scanner. No vendor workaround exists, so the control has to come from upstream.
Re-run the app dork quarterly and treat any change as a deployment event worth explaining.

The methodological conclusion

A zero on a CVE dork is evidence about the index's version visibility and nothing else. Quoting it as reassurance in a report about a KEV-listed vulnerability is the specific error this piece exists to prevent. The number to trust is the one collected from the appliance.

References

ZoomEye search: https://www.zoomeye.org/
Cisco advisory cisco-sa-esa-afw-zqYJkjxp for CVE-2026-76519