DEV Community: OnaEiuspkz

Repeating the Measurement: What Changed Between Two ZoomEye Snapshots

OnaEiuspkz — Wed, 07 Oct 2026 04:00:35 +0000

Repeating the Measurement: What Changed Between Two ZoomEye Snapshots

ZoomEye queries on 26 September 2026 returned 734,693 matches for app="RabbitMQ", 350,891 for app="Elasticsearch", 257,126 for app="MinIO" and 92,859 for app="Apache ZooKeeper". Each figure is close to a value measured in an earlier collection round without being identical, and those differences are the subject of this article.

Context and method

All counts here come from single ZoomEye queries executed through the search API on 26 September 2026 at 00:38 China Standard Time, with page 1, page size 1 and sub_type all. An earlier collection round, run in the same way, produced 735,408 for RabbitMQ, 350,497 for Elasticsearch and 256,552 for MinIO.

Why repeated counts differ

An internet-wide scanner measures a moving population. Hosts appear, disappear and change configuration continuously. A service is installed, an address is reassigned, a device is decommissioned, a firewall rule is tightened or loosened. Any second measurement of the same query will differ from the first, and the size of the difference depends on how quickly the underlying population turns over.
That means a difference of a few hundred on a total of hundreds of thousands is not a trend. It is the expected variation between two samples of a dynamic population. Reporting it as growth or decline overstates what a single pair of measurements can show. A trend requires many measurements at consistent intervals, taken the same way, with the query and the vantage points held constant.

The ZooKeeper comparison

The ZooKeeper figures illustrate a different trap. An earlier article reported 272,927 for ZooKeeper, and the current measurement of app="Apache ZooKeeper" returned 92,859. Those two numbers are not comparable, and the query itself is the reason. A dork that names the product with a different spelling, or that matches a field such as a banner instead of a product label, describes a different set of hosts.
The lesson generalises. Before treating two numbers as a change over time, confirm that the queries were identical. Dork syntax, field selection, sub_type and case sensitivity all affect the result, and the fuzzy and exact match operators behave differently. A count without its query text is not reproducible, and an unreproducible count cannot support a trend claim.

What the numbers do support

They support a statement about scale at a moment in time. RabbitMQ with more than seven hundred thousand matches, Elasticsearch above three hundred fifty thousand, MinIO above two hundred fifty thousand and ZooKeeper approaching one hundred thousand describe an internet in which message brokers, search clusters and object storage endpoints are widely reachable.
For each of these four, the operational question is the same and does not depend on the exact count. Is the service reachable from outside the network that uses it, and is authentication enabled? RabbitMQ and Elasticsearch both support authentication and both have long histories of deployments found without it. MinIO requires credentials for its interface, but exposed consoles still disclose the existence and often the naming convention of the buckets behind them. ZooKeeper was designed for trusted networks and authenticates clients optionally.

Implications and next steps

Record the query text alongside every count, and record the collection time and the sub_type parameter. A number without that context cannot be compared to a later reading, and the comparison is the only thing that turns a measurement into intelligence.
Set a variation threshold before drawing conclusions. For a population in the hundreds of thousands, differences of a fraction of a percent over days are noise. Decide what magnitude would indicate a real change, and only then treat a reading as a signal.
Then use the counts for what they support. They establish that a technology is widely reachable and therefore worth a configuration review. The review itself happens inside the network, against an inventory, and the internet scan only tells you which technologies to look for.

Scope and limitations

These are point-in-time fingerprint counts from ZoomEye's vantage points. They include cloud provider ranges, research networks and honeypot hosts, and they count each reachable node separately, so a single deployment contributes multiple matches. Variations between collection rounds reflect the dynamics of the public internet and the behaviour of the scanner as well as real changes. Nothing here measures exploitation or patching status.

References

ZoomEye search API results for app="RabbitMQ", app="Elasticsearch", app="MinIO" and app="Apache ZooKeeper", collected 26 September 2026.
Earlier collection round results for the equivalent dorks, used only for comparison.

Finding WordPress Click2Shell Exposure Starts With Knowing Where WordPress Runs

OnaEiuspkz — Wed, 07 Oct 2026 01:40:34 +0000

Finding WordPress Click2Shell Exposure Starts With Knowing Where WordPress Runs

On September 21, 2026, security researchers disclosed Click2Shell, an unauthenticated remote code execution chain in WordPress Core. An attacker needs no WordPress account. A single visit by a logged-in administrator to a crafted link is enough: the browser installs a catalog theme on its own, and the theme's unprotected AJAX endpoint downloads and executes attacker-controlled PHP. WordPress fixed the core parser flaw in version 7.1.1. No CVE identifier has been published yet, and researchers confirmed no exploitation in the wild at disclosure time.
Before any team can prioritize this fix, it needs an answer to a simpler question: where does WordPress actually run in the environment we are responsible for?

Why inventory comes first

WordPress is famously large. A ZoomEye query for app="WordPress", executed on September 22, 2026 (UTC), returned 7,945,496 matching assets worldwide. That number counts indexed WordPress product assets. It does not mean those hosts are vulnerable, and it does not mean they were attacked. What it does show is scale: any WordPress Core flaw touches an asset population too large to handle by memory or spreadsheet.
For an organization, the relevant subset is smaller. WordPress instances behind the corporate perimeter, on partner-facing hosts, or on forgotten staging servers all count. The Click2Shell chain makes forgotten instances especially interesting, because the attack path runs through an administrator's browser session rather than through obvious network exposure.

What ZoomEye can and cannot verify here

ZoomEye's role in this event is verifiable asset discovery, not vulnerability confirmation. The fingerprint query app="WordPress" identifies hosts presenting WordPress signals. Teams can narrow it with geographic or network filters that match their own scope, for example combining the product fingerprint with a known ASN or CIDR to spot instances registered to their address space that never entered the CMDB.
Three limits deserve explicit statement:

A matching asset is not a confirmed vulnerable asset. The core parser weakness affects versions before 7.1.1, but ZoomEye's product fingerprint does not, by itself, prove a specific patch level.
The count is a point-in-time observation. The 7.9 million figure was collected on 2026-09-22 and will drift as indexing continues.
The theme-side flaw (Mobile Repair Zone 2.5.4 and over 40 other catalog themes) lives inside third-party packages that a product-level fingerprint cannot see.

A defensible first step

For the Click2Shell event, asset identification is the step that makes every later step possible: patch tracking needs a host list, theme audits need an installation list, and incident review needs a scope. A ZoomEye product query, recorded with its query string, execution time and total, gives teams a documented starting point they can repeat and compare over time.

References

SecurityOnline.info, "WordPress Click2Shell Vulnerability Triggers Core RCE, PoC Published", September 21, 2026.
pwn.ai research report on the Click2Shell chain, as cited by the source article.
ZoomEye query record: app="WordPress", 2026-09-22, 7,945,496 results.

Apache NiFi at 6,093 observed hosts: a data flow controller and the credentials it holds

OnaEiuspkz — Tue, 06 Oct 2026 19:00:32 +0000

The number

A ZoomEye query for app="Apache NiFi" returned 6,093 matching hosts, collected on 2 October 2026 with sub_type=all and a page size of one record. The total is the match count for the fingerprint. A smaller figure than the monitoring or observability products, and one that still deserves attention because of what the software does rather than how many instances run it.

What NiFi represents

NiFi moves data between systems. A flow is a graph of processors that read from a source, transform the payload and write to a destination. To do that it stores connection details for every system at both ends of the flow, and the flow configuration therefore contains credentials for databases, message brokers, object stores and APIs.

The interface also supports building and running flows, which means an authenticated session can redirect where data goes. The distinction between reading the configuration and acting on it is the difference between a disclosure and a data exfiltration path, and the software provides both.

What the count does not say

6,093 hosts identify as NiFi. It does not say how many allow anonymous access or use a default credential, how many sit behind a single sign-on proxy, or how many are development instances with synthetic data. NiFi's own configuration includes a setting that permits anonymous access, and its documentation describes the single-user and multi-user modes, so the answer depends on which mode each deployment chose.

Why the exposure matters

A flow configuration is a map of an organisation's data movement, and the parameters in it include the endpoints, the topics, the bucket names and the credentials. Even without the ability to modify a flow, reading the configuration narrows a large environment to the systems that matter. With the ability to write one, a new processor can send data to an address of the attacker's choosing.

What to do

Require authentication and remove anonymous access deliberately rather than by default assumption. Put the interface behind a network control or a proxy that enforces authentication, and check that the registration or single sign-on configuration is the intended one rather than the sample configuration shipped in a tutorial.

Review the flow parameters that contain credentials and consider moving them to a controller service with a protected type, so that reading a flow does not read a secret. Restrict the interface to the operator network, and record which accounts can modify flows as opposed to viewing them.

References

Apache NiFi documentation. https://nifi.apache.org/docs.html
ZoomEye. https://www.zoomeye.ai/

Plane at three fields and three answers: 12,510 titles, 358 fingerprints and 72 product matches

OnaEiuspkz — Tue, 06 Oct 2026 18:40:32 +0000

Plane at three fields and three answers: 12,510 titles, 358 fingerprints and 72 product matches

When three fields return three different numbers for one product, the instinct is to look for the correct one. For Plane, a project management platform, the more useful response is to establish what question each field answers and to stop treating them as competing estimates of one quantity.

Context and method

Queries ran through the ZoomEye SDK on 2026-10-05 with sub_type=all, page=1 and pagesize=1. Page size limits returned records, not matched totals.

Search: title="Plane" returned 12,510.
Comparison: app="Plane" returned 358.
Comparison: product="Plane" returned 72. All three figures describe globally indexed assets at collection time. None indicates that a workspace is reachable, unauthenticated or vulnerable.

What separates the numbers

The title figure is the most permissive of the three, and for a short and common word it is also the least precise. A product name that can appear as an ordinary noun will accumulate matches from pages where the word is used for other reasons, which is a specific hazard here that was not a factor for the longer product names measured elsewhere in this series.
The application field is stricter, since it depends on recognisable behaviour rather than on a string. Its value is the most plausible population indicator of the three, subject to the usual caveat that client-rendered interfaces reduce coverage.
The product field reflects a component-level representation that covers some application classes and not others. As with other products measured in this series, a value one or two orders of magnitude below the fingerprint count is a coverage statement rather than a deployment statement.

Why the platform is worth reviewing

A project management platform holds the organisation's plans, issue descriptions, attachments and, in many deployments, the integrations that connect it to source control, chat and automation. The integration credentials are the sensitive part: a task tracker that can post to a chat channel, merge a pull request or trigger a deployment is a system with standing authority, and its own authentication is the only barrier in front of that authority.
Public projects add a second dimension. Where a workspace has published projects for external visibility, the same application serves both an intentionally public surface and a private one, and the distinction depends on configuration that an external observer cannot verify.

Reporting method

Report each field with its query and collection time, and describe what it measures rather than ranking the three into one figure. Where a product name is a common word, state that the title field over-collects and prefer the fingerprint field for population questions. Where the fingerprint field returns a very small number for a widely deployed product, state that the field does not cover the application class.

Limitations

This is a single collection, and the three figures are not directly comparable to counts gathered under a different sub_type. No claim is made about the security posture of any deployment. The title field in particular should not be used for trend analysis for a name of this kind.

References

ZoomEye, title="Plane" (12,510), app="Plane" (358) and product="Plane" (72), sub_type=all, collected 2026-10-05.
Plane project documentation, workspace and integration configuration.

Metabase on 116,913 observed hosts: business intelligence as an unguarded data path

OnaEiuspkz — Tue, 06 Oct 2026 15:20:31 +0000

The number

A ZoomEye query for app="Metabase" returned 116,913 matching hosts, collected on 2 October 2026 with sub_type=all and a page size of one. The count is the fingerprint match total. Business intelligence platforms appear in large numbers because they are easy to deploy and often land on a shared host with a memorable address.

Metabase connects to databases with a stored connection, and the questions and dashboards it renders are SQL that runs against those databases. The application is therefore an authenticated proxy to every connected data source.

What the surface exposes

An installation that has completed first-run setup presents a login. An installation that has not presents a setup page that creates the first administrator, which is the case worth searching for because it converts an exposed instance into full control of the connected databases.

Beyond that, the public sharing feature allows a question or dashboard to be published at a link without authentication, and the feature is enabled by default unless it has been turned off. A shared link reveals whatever the underlying query returns, including data the sharing administrator may not have considered sensitive when the link was created.

What the count does not say

116,913 hosts identify as Metabase. It does not say how many have completed setup, how many have public sharing enabled, or how many databases each can reach. Those are per-instance facts, and they are exactly the facts a defender should collect internally rather than infer from a scan.

Why the exposure matters

The platform concentrates database credentials in one place and presents them through an interface designed for ease of use. Database connections are frequently created with administrative or read-all accounts because that is the path of least resistance during a trial. A single account takeover therefore reads any table the connected account can read, and the list of connected accounts is visible in the interface.

What to do

Disable public sharing where it is not required, and review existing share links for content that has changed meaning since publication. Review the database connections and replace broad accounts with roles limited to the tables the platform actually serves.

Require authentication through the platform or an upstream proxy, keep the instance on an internal network, and check whether the setup flow has been completed on every deployment rather than only the primary one. Where several copies exist for testing, treat them as in scope, because a test copy usually carries a copy of the production connection.

References

Metabase documentation. https://www.metabase.com/docs/latest/
ZoomEye. https://www.zoomeye.ai/

After CVE-2026-104286: A Compromise Assessment Plan for FortiMail

OnaEiuspkz — Tue, 06 Oct 2026 03:40:31 +0000

After CVE-2026-104286: A Compromise Assessment Plan for FortiMail

Start from the exploitation window

CVE-2026-104286 is a CVSS 9.8 path traversal in Fortinet FortiMail that allows unauthenticated file writes through crafted HTTP or HTTPS requests. Fortinet reports exploitation in the wild, and CISA added the issue to its Known Exploited Vulnerabilities catalog on October 1, 2026.

If the management interface was internet-reachable, assume the window applies and investigate rather than assuming safety.

High-value checks

Review the appliance for modified binaries and unexpected library preloads. Check whether files exist in directories the application does not normally write to, and whether configuration changed outside a recorded change. Compare current state against a known-good baseline where one exists.

On the network side, look for outbound connections to hosts the appliance has no business contacting. Mail gateways legitimately talk to many destinations, so baseline the expected set first.

Handling a confirmed compromise

Treat it as a containment event. Isolate the appliance, preserve evidence for analysis, and rebuild from a trusted image rather than cleaning in place. Rotate credentials the appliance held, and review mail flow rules for unauthorized changes.

Close the loop

Document what was checked and what was found. That record supports both a defensible conclusion and a faster response if a related Fortinet advisory appears later. Full remediation still means upgrading to a fixed build and migrating off the 7.0 branch, which has no named fix.

References

Fortinet PSIRT advisory FG-IR-26-175 covering CVE-2026-104286.
CISA alert, "CISA Adds One Known Exploited Vulnerability to Catalog," October 1, 2026: https://www.cisa.gov/news-events/alerts/2026/10/01/cisa-adds-one-known-exploited-vulnerability-catalog
CVE.org entry: https://www.cve.org/CVERecord?id=CVE-2026-104286
securityonline.info report: https://securityonline.info/fortimail-vulnerability-cve-2026-104286/

CVE-2026-65660: a SharePoint code injection reachable with an ordinary user account

OnaEiuspkz — Tue, 06 Oct 2026 01:20:31 +0000

CVE-2026-65660: a SharePoint code injection reachable with an ordinary user account

SharePoint is rarely treated as a perimeter system, which is why a flaw in it reads as lower priority than an edge appliance. CVE-2026-65660 changes that calculus. The vulnerability is a code injection in Microsoft SharePoint Server, added to the KEV catalog after exploitation was observed, and it is reachable by an authenticated user with low privileges.

What the flaw is

The vulnerability is a code injection in SharePoint Server. The distinction from a remote unauthenticated flaw is important: the attacker needs an account, which means the entry point is more likely to be a phished credential, a contractor account, or a service account that was left with interactive access than a mass scanning campaign.

Why an authenticated flaw is still a serious one

An attacker with a valid low-privilege account already has what a scanner does not: a legitimate session, a valid audit trail, and the ability to reach internal resources that are not exposed to the internet. In a document management platform the account can create content, and content is processed by other users and by server-side components.
Detection also suffers. Requests from an authenticated user sit inside normal traffic, so the signal is behavioural rather than structural. A spike in requests to server-side component paths from one account, or requests that arrive outside that account's normal working pattern, is closer to what an investigation can actually use.

Why document platforms keep producing injection bugs

A collaboration platform is a set of server-side renderers, converters and web parts assembled over many years, and each of them accepts structured input. Code injection tends to appear where a component builds executable content from data that a user supplied, and where the boundary between data and code is defined by convention rather than enforced by the runtime.

What to do

Apply Microsoft's updates for the affected SharePoint Server versions. Confirm which farms are still in scope, since SharePoint estates commonly include older farms that were kept for a single application.
Given confirmed exploitation, presume the entry point was a real account and review it. Look at authentication events for accounts with privileges well beyond their role, at new site collections and web parts created recently, and at outbound connections from SharePoint servers to destinations that are not part of normal integration traffic.

References

iThome weekly security roundup, 2 October 2026, https://www.ithome.com.tw/news/179381
Daily security intelligence report, 1 October 2026, https://blog.csdn.net/weixin_45635831/article/details/166945207

Rancher on 23,600 observed hosts: a management console with credentials for many clusters

OnaEiuspkz — Mon, 05 Oct 2026 18:40:29 +0000

Rancher on 23,600 observed hosts: a management console with credentials for many clusters

A ZoomEye fingerprint query for app="Rancher" (result list) returned 23,600 matching hosts at collection time, with sub_type=all, page 1 and page size 1. Rancher is a Kubernetes management platform, and the relatively modest count fits a product that is usually deployed inside an organisation rather than on a public address.

What the console holds

Rancher manages clusters rather than running application workloads directly. The web interface listens on 443 by default, with the original HTTP port 80 available for redirects. A Rancher server stores the credentials it uses to talk to every managed cluster, along with user accounts, roles and project assignments. That is a centralised trust store by design, and it is the reason the console is a high value target: an attacker who reaches it with valid credentials can act across the whole estate, and an attacker who finds an authentication weakness inherits the same reach.

Historically the product shipped with a bootstrap password that had to be set on first login. Deployments that were stood up in a hurry and never finished that step are the ones where a default credential can still work.

Checks for operators

Confirm that the bootstrap admin account has been rotated, and that multi-factor authentication is required for accounts with cluster-wide privileges.
Keep the console on an administrative network and avoid publishing it to the internet, even on a non-standard port.
Review the external authentication configuration, since a misconfigured provider can widen access beyond the group that was intended.
Watch the audit log for cluster registration events and role changes that no change record explains.

What the count supports

A fingerprint match indicates that a host looks like a Rancher server. It does not confirm reachability, credential state or the number of clusters behind it. The value of the number is in the question it raises: whether any management console in your estate is reachable from a network that the console was never meant to serve.

Subdomain Takeover: The Dangling Record That Keeps Handing Out Your Brand

OnaEiuspkz — Mon, 05 Oct 2026 18:20:29 +0000

Subdomain Takeover: The Dangling Record That Keeps Handing Out Your Brand

A subdomain takeover is one of the few vulnerabilities that a defender can confirm without touching the target. The DNS record is public. If it points at a third-party service that no longer claims the name, anyone who can register that name at the same provider gets the subdomain, and with it the trust the parent domain extends.
The finding is unglamorous and persistent. It survives domain migrations, marketing campaigns, and reorganisation, because the record lives in a zone file and the service lives in someone else's account, and no single person owns both.

The mechanism, plainly

An organisation points something.example.com at a third-party host, typically by creating a CNAME to a provider-assigned hostname. That is the standard way to serve a marketing site, a help centre, a status page, or a project preview.
The service is later decommissioned. The team deletes the content at the provider, or the account lapses, or the subscription is cancelled. The DNS record remains, because it was created by a different team through a different process.
The provider's hostname is now unclaimed. Many providers assign hostnames that are derived from a project name or a slug, and when the original claim is released, a new account can claim the same name. The new account holder now answers for something.example.com.
The impact depends on what the parent domain trusts. Cookies scoped to the parent domain can be set by the taken-over host, which is why cookie prefixes matter. Email authentication records may align against the parent domain. Content served from the subdomain inherits the brand, which is what makes it useful for phishing or for hosting payloads that security controls treat as first-party.

Finding them without an agent

The discovery method is entirely passive, which is what makes it worth doing on a schedule.
Enumerate the subdomains of the domains you own. Public certificate transparency logs are a rich source, because every certificate issued for a subdomain is logged. Passive DNS sources and your own resolver logs add names that certificates miss.
Resolve each name and record where it points. For each CNAME, compare the target against a maintained list of provider patterns and their released-name fingerprints. The fingerprint is usually the provider's own error page or a specific HTTP response, and the pattern list is worth maintaining as a data file rather than in someone's memory.
Charge the record to a verification step, not to a finding. A CNAME that points at a live, claimed service is not a takeover; it is normal. The distinguishing evidence is that the provider does not recognise the name and the content it serves is not yours.

The problem with one-time scans

A takeover scan answers today's question. The records that matter are the ones that appear between scans.
The durable approach is to own the record lifecycle. Every DNS record that points at a third-party service should have an owner and a purpose attached to it, and the decommissioning process for that service should include the DNS record. The failure is not that the scan did not run. It is that nobody was accountable for the record when the service ended.
Where the zone is large and the ownership is unclear, the practical alternative is continuous discovery with alerting. Certificates are still issued for subdomains you may not know about, and a new CNAME is a leading indicator of a new unmapped dependency.

Controls that reduce the blast radius

Three controls make a takeover less useful even if it happens.
Set session cookies with the __Host- prefix, which restricts the cookie to the exact host and prevents a sibling subdomain from setting a cookie scoped to the parent domain.
Keep email sending domains and the primary domain separated where the mail architecture allows it, so that a subdomain failure does not undermine alignment.
Monitor what is served from your subdomains. A takeover changes content, and the change is visible before anyone reports a phishing page that uses your brand.

What to take away

Subdomain takeover is a lifecycle failure with a technical symptom. The scan is cheap and should run continuously, but the fix is an inventory in which every record that delegates trust to a third party has an owner and a removal step. The finding to act on is not "we have a dangling CNAME." It is "we did not know this dependency existed."

References

OWASP, Subdomain Takeover
MITRE ATT&CK, T1584.001: Compromise Infrastructure - Domains
RFC Editor, RFC 6265bis: Cookies (__Host- prefix)
Certificate Transparency, CT log search

Auditing file-serving permission checks, using CVE-2026-100727 as the model

OnaEiuspkz — Mon, 05 Oct 2026 15:00:37 +0000

Auditing file-serving permission checks, using CVE-2026-100727 as the model

Why this audit is worth running

CVE-2026-100727 affects GROWI versions before v7.5.5 and allows a remote unauthenticated attacker to read files contained in non-public pages when the file upload setting is configured as "Local". The advisory JVN#24352487 classifies it as CWE-552 and scores it 6.9 on CVSS 4.0 and 5.3 on CVSS 3.0. The vendor fixed it in version 7.5.5, released on 2026/10/05, after a coordinated report through JPCERT/CC.
The GROWI case is a clean example of a class of bug that appears across many platforms: an application applies a permission check to the page and a weaker one, or none, to the stored file the page references. Reviewing for that pattern is cheap compared with discovering it through an incident.

The check that matters

For every endpoint that returns stored bytes, ask which permission decision gates it and which object that decision is evaluated against. The correct answer names the owning record, not the storage path. A path-based check answers a different question, namely whether the requester can name the object, and naming an object is not an authorisation decision.

Where the pattern hides

Static file routes registered outside the application's request pipeline, which never pass through the middleware that carries the session
Download endpoints that accept an object identifier and read it directly
Signed-URL features whose signature covers the path but not the current permission state, so a link stays valid after the owner revokes access
Attachment rendering inside editors, which may fetch referenced files through a separate handler
Archived or exported content bundles that reproduce the original paths without the original checks

A repeatable review

Enumerate every route that can return file-like content, including routes mounted by libraries and by static handlers.
For each route, record the gating decision and the object that decision reads.
Compare that object with the object the user interface protects.
Test anonymously against a private-page attachment and record the outcome.
Repeat the test after each upgrade that changes file handling, since a refactor can move the gate without removing it.

Affected products and scope

For this CVE specifically, the affected combination is GROWI before v7.5.5 with the file upload setting configured as "Local". Other platforms require their own mapping of the check to the endpoint, and the review method above applies to them without modification.

Exposure context

On 2026-10-05 a ZoomEye query for hosts that display the product name in the page title returned 401 records:
Search Dork: title="GROWI"
The figure describes product surfaces, not vulnerable instances, and it cannot report which upload backend each host uses.

Remediation and mitigations

Patch to GROWI v7.5.5. Confirm the fix by testing the anonymous request path. Where local storage remains in use, treat it as a configuration to verify after every future upgrade, and keep the attachment inventory current so a disclosure window can be scoped quickly.

References

Server-side request forgery: the redirect that walks past your allowlist

OnaEiuspkz — Mon, 05 Oct 2026 03:20:30 +0000

Server-side request forgery: the redirect that walks past your allowlist

What makes SSRF resilient

A server that fetches a URL supplied by a user is making the request from a position of trust. The classic outcome is access to an internal service, and the modern high-value target is the cloud instance metadata endpoint, which on many platforms answers on the link-local address 169.254.169.254. The metadata service hands out temporary credentials to anything that asks from the instance, which turns one HTTP request into control of the workload's cloud identity.

The reason simple filtering fails is that the attacker chooses the redirect chain as well as the first URL. A fetched resource can answer with a redirect to an address the allowlist would have rejected, and a client that follows redirects automatically has already made the request by the time any check runs.

Why allowlists still win, and where they leak

OWASP's guidance puts allowlists first, and the reasoning holds: the set of destinations a feature legitimately needs is almost always small and enumerable. A denylist has to anticipate every representation of an internal address, including decimal, octal and hexadecimal forms, IPv6 mapped forms, and DNS names that resolve to internal addresses after the check.

The leak is the gap between the check and the use. If the address is validated once and the request is then made by a client that resolves the name a second time, a DNS record that changes between the two lookups defeats the validation. If the client follows redirects, the validation applies to the first hop only. Both are time-of-check to time-of-use problems, and both are fixed by validating at the point of use.

A design that holds

Resolve the name, validate the resulting address, and connect to that address directly rather than to the name. Disable automatic redirect following and handle redirects explicitly, revalidating each hop against the same rules. Restrict the scheme to HTTPS and set a short timeout. Where the fetch can reach a metadata endpoint, use the platform control: on AWS, IMDSv2 requires a session token that a simple SSRF cannot obtain, and lowering the hop limit restricts which processes on the instance can reach the service.

Where the feature only needs to fetch from a known set of hosts, replace URL input with a host identifier and build the URL from a template. That removes attacker control over the destination entirely and is the only design with no bypass class of its own.

Testing

Send a request that points at the metadata address directly and confirm it is refused. Then send a request that points at a controlled external host that responds with a redirect to the metadata address, and confirm the redirect is either refused or revalidated. The second test is the one that finds the gap, and it is cheap to run whenever the fetch code changes.

References

Server-Side Request Forgery Prevention Cheat Sheet, OWASP. https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html
Configure the instance metadata service, Amazon EC2 User Guide. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html
RFC 9110, HTTP Semantics. https://www.rfc-editor.org/rfc/rfc9110.html

oc-mirror CVE-2026-75939: A Signature Check That Runs in the Wrong Order

OnaEiuspkz — Mon, 05 Oct 2026 01:00:29 +0000

oc-mirror CVE-2026-75939: A Signature Check That Runs in the Wrong Order

Red Hat disclosed CVE-2026-75939 on 21 September 2026 with a CVSS v3.1 score of 7.4. The affected component is openshift4/oc-mirror-plugin-rhel9 in Red Hat OpenShift Container Platform 4. The tool that syncs release images, operator catalogs and related content into a private registry can be made to accept a forged PGP message, and the defect is one of ordering.

The logic error

According to the vendor advisory, oc-mirror has a validation order defect when processing PGP-signed release images. The tool performs the signature error check before it has finished processing the full signed message body. A forged PGP message that carries a legitimate Red Hat release key id can therefore be judged trustworthy, because the check is completed on incomplete input.

What an attacker needs and gains

Exploitation requires the ability to intercept or modify traffic between an affected oc-mirror instance and the signature endpoints. No prior privileges are needed and no user interaction is required, and the impact on confidentiality and integrity is rated high, with no availability impact. The attack complexity is high for that reason: the traffic manipulation has to succeed.
If it does, the tool syncs a malicious release payload into the private registry of a disconnected environment. Disconnected and air-gapped estates treat registry content as reviewed software, which is what makes the outcome a supply-chain problem rather than a single-host compromise. Once the payload is in the registry, an administrator or an automated installation pipeline can select it and deploy it, after which the cluster faces unauthorized code execution, application tampering, credential theft and unauthorized access to sensitive data.

Scope detail worth noting

The RHEL 8 variant of the plugin is not affected because the component does not exist in that release. Older packages in supported minor product branches inherit the flaw unless the advisory marks them as unaffected. Red Hat stated that at disclosure there was no practical mitigation that met its deployment and stability standards.

Practical mitigation

Restrict network access from oc-mirror hosts to the signature endpoints, and be deliberate about deploying TLS inspection, since the same interception capability is what the flaw requires.
Monitor private registries for unexpected changes to synced content.
Verify release image digests through an independent trusted channel before promoting anything to production.
Review access control on the private registry and audit what has been synced recently.
Track the Red Hat security advisory channel for the fixed package.

References

Red Hat, oc-mirror advisory referenced from the disclosure summary: https://access.redhat.com/security/security-updates/
FreeBuf, 红帽披露OpenShift重要漏洞，可绕过PGP校验推送恶意镜像: https://m.freebuf.com/column/502644.html
51Testing summary of the same advisory: http://www.51testing.com/?action-viewnews-itemid-7811566