DEV Community: StarkMan

3,121 Owncast Servers: Security When the Application Is Meant to Be Public

StarkMan — Sun, 11 Oct 2026 11:00:44 +0000

Owncast is a self-hosted live streaming server. It is a single-binary application, it is designed to be run by one person for one stream, and it is often deployed for a community, a conference, or a personal channel. That combination, an internet-facing application built for publishing to a public audience, produces an exposure pattern worth thinking about.

The count

A title query returns 3,121 services. For a niche product in the self-hosted streaming space, that is a healthy footprint, and the design of the tool explains why: it is easy to run, it does not need a large infrastructure, and it can start as a small experiment and then be left running.

The public-by-design problem

Streaming software is unusual because its function is to be reachable. An Owncast instance that is not reachable is not doing anything. So unlike a database or an admin panel, this class of application cannot be moved behind a VPN as a general control, and the security question shifts from reachability to what else the service exposes.
That other surface is the administration interface. The same deployment that publishes video also has an operator back end for starting streams, changing settings, and managing the channel. If the admin path is protected only by a password, and the operator set that password when they stood up the instance and never revisited it, then the exposure is the usual one, attached to a process that may run with more system privileges than the streaming function needs.

What a compromised stream server means

Three consequences are specific to this category. Publishing to the audience is the first: an attacker who controls the stream can put anything on the channel under the operator's identity, and the audience has no way to tell. Privacy of the audience is the second, because chat and viewer state accumulate in the same application. Resource abuse is the third, since a streaming server has bandwidth, and a compromised one can be turned to other ends.
Running the process as a dedicated, unprivileged user with limited network and filesystem access is the containment that makes the difference between a hijacked channel and a hijacked host.

Hardening

Change the administrative credentials from any default and use a strong unique passphrase rather than a reused one. Put the admin interface behind the organisation's identity provider or an IP allow-list if remote administration is only occasionally needed. Keep the application current, apply TLS through a reverse proxy rather than the bare service, and give the process its own user account. If the instance is a personal stream, the honest advice is the same as for any internet-facing hobby service: assume it will be found, and make what a visitor can reach match what you meant to publish.

Using the measurement

3,121 services is a modest, trackable population. The valuable refinement is not a bigger number but a more specific one: how many of these instances render an admin login on the same host, and how many publish version information that makes targeting trivial. Those narrower queries turn a category count into an actionable set.

References

ZoomEye, title query title="Owncast": 3,121 matching services. https://www.zoomeye.org/searchResult?q=dGl0bGU9Ik93bmNhc3Qi
ZoomEye, the search platform used for these queries. https://www.zoomeye.org/

McKesson, ShinyHunters and the Vishing Path Through Okta Into Salesforce and Snowflake

StarkMan — Sun, 11 Oct 2026 07:00:44 +0000

McKesson, ShinyHunters and the Vishing Path Through Okta Into Salesforce and Snowflake

McKesson disclosed a security incident on 25 August 2026, filing an 8-K with the US Securities and Exchange Commission. The company confirmed unauthorised access to a third-party application and exfiltration of data, affecting a subset of customers in its oncology and multispecialty, and medical-surgical business units. The extortion group ShinyHunters claimed responsibility and described how it got in.

No exploit was involved

The campaign that ShinyHunters described did not rely on a software vulnerability. The group said it used voice phishing against multiple McKesson employees to obtain their Okta single sign-on accounts, then used the resulting sessions to reach the organisation's Salesforce and Snowflake environments.
That pathway is effective for unglamorous reasons. A voice call asking a member of staff to complete an authentication step produces a valid session in a legitimate identity provider. Nothing about the login looks anomalous, because it is not anomalous. The account holder did authenticate. From the identity provider's perspective, the employee granted access.

What was reached, and what was taken

The claimed tradecraft is specific about the resources. ShinyHunters said it took full control of the Salesforce environment, including support tickets, and pulled a substantially larger volume from Snowflake.
The group stated it exfiltrated approximately 1 TB over four days between 21 and 25 August. It claimed roughly 284 million patient-related records. On that figure the group was unusually explicit, clarifying to reporters that the number is a raw row count from the database, not a deduplicated count of affected individuals. One person can appear many times across prescriptions, appointments and claims.
That distinction is not pedantry. It is the difference between a breach affecting a population and a breach affecting a dataset, and it changes how regulators and affected individuals should read the number.
The data categories claimed include names, addresses, dates of birth, Social Security numbers, patient identifiers, medical record numbers, prescriptions, allergy information and physician details, alongside personal information belonging to McKesson employees.
The ransom demand was reported at roughly 55 million dollars, with a reported 72-hour response window. McKesson did not comment on the figure.

What McKesson confirmed

It is worth being precise, because the difference between what a company confirms and what an attacker claims is the difference between evidence and assertion.
McKesson confirmed that a third-party application was accessed without authorisation, that data was exfiltrated, that the affected population is a subset of customers in specific business units, and that its investigation was at an early stage. The company said its core distribution operations were not interrupted and that it had no reason to believe unauthorised activity was ongoing. It had not, as of the filing, determined that the incident was material to its financial results.
McKesson did not confirm the vishing entry path, did not identify the third-party application, and did not confirm the scale or the specific categories of the leaked data. The attack chain is the attacker's account.

The infrastructure behind the phishing

Reporting identified at least one domain used in the campaign in the form mckesson[.]claims. That pattern matches a broader campaign documented by threat researchers, in which the group registers .claims domains containing the target organisation's name or abbreviation to impersonate helpdesk and IT teams.
The technique is not sophisticated and that is the point. A domain that carries the company name and a top-level domain that reads as official is enough for a plausible approach to an employee who is being asked to do something routine.

The warning that came first

The Health Information Sharing and Analysis Center issued an advisory in July 2026, roughly two months before McKesson's disclosure, warning that ShinyHunters was increasingly using vishing and related social engineering to take over single sign-on accounts and then compromise the cloud applications connected to them.
A specific, timely warning about a specific technique, in a sector where the group was already active, did not prevent this incident. That is worth stating without judgement, because it describes a real operational gap: threat intelligence that describes a technique does not by itself change whether employees can be reached by phone and whether an SSO session grants access to a warehouse full of data.

What actually reduces this risk

Number one is phishing-resistant authentication. Voice phishing defeats one-time codes, including those delivered by SMS and by authenticator apps, because the attacker asks the user to read the code out. FIDO2 security keys and passkeys bind the credential to the origin and cannot be relayed to an attacker over a phone call.
Number two is scoping. The blast radius in this incident was set by what a single employee's SSO account could reach. Privileged access should be separately gated, and warehouse or analytics environments should not be reachable with a routine business account without a second control.
Number three is monitoring for the behaviour rather than the login. Bulk export from an analytics platform, unusually large query result sets, downloads of support ticket data, and access from new locations are the signals that survive valid authentication. Session anomaly detection on SaaS platforms is more useful here than perimeter defence, because nothing crossed the perimeter.
Number four is speed on the human side, which is unglamorous and effective: tell employees that IT and helpdesk will never ask them to read out an authentication code, and give them a way to report a suspicious call that does not require them to be certain first.

References

Healthcare giant hit: 284 million patient records suspected exfiltrated: https://new.qq.com/rain/a/LNK2026083116051400
Vishing, SSO account takeover and healthcare data exposure: the McKesson case: https://cloud.tencent.com/developer/article/2737616
McKesson security incident case analysis: https://www.sohu.com/na/1071321794_120780361
Weekly threat briefing, 28 August to 3 September 2026: https://xxzx.dqsy.net/info/1095/1792.htm

A Date Filter Is Not an Install Date: Reading Time-Bounded Exposure Queries

StarkMan — Sat, 10 Oct 2026 18:20:42 +0000

A Date Filter Is Not an Install Date: Reading Time-Bounded Exposure Queries

The NCSC summary of the May 2020 US sanction describes a change that took effect in 2020. Relating an exposure measurement to that date requires care about what a time filter means.

Bounding the observation

On 4 October 2026, app="Huawei" returned 18,927,766 matches and app="Huawei" && after="2020-05-15" returned 17,653,722.
| Query | Scope | Matches observed |
| --- | --- | ---: |
| app="Huawei" | All records | 18,927,766 |
| app="Huawei" && after="2020-05-15" | Records after a date | 17,653,722 |

What `after` refers to

A date filter in a scanning platform applies to the last time the record was updated in that platform, not to when a device was installed, purchased or deployed. A router installed in 2015 and re-observed in 2024 will sit after a 2020 cut-off.
That is why the large majority of matches fall after the date. The number describes observation recency, not procurement history.

The honest use of a time filter

The filter is useful for narrowing to records that were seen or refreshed recently, which helps when you want a current picture rather than a historical one. It cannot be used to claim that a device appeared because of a specific 2020 policy change.

Practical next steps

State that a date filter refers to record recency.
Use date filters to select fresh observations, not to date installations.
Never attribute a device's presence to a policy event based on a date filter.
Keep the unfiltered and filtered counts side by side.

Limitations

Record timestamps depend on the platform's own observation schedule, which may be uneven by region and network.

References

NCSC, Summary of the NCSC analysis of May 2020 US sanction: https://www.ncsc.gov.uk/report/summary-of-ncsc-analysis-of-us-may-2020-sanction
ZoomEye: https://www.zoomeye.ai/

Internal certificate authorities fail on lifecycle, not on cryptography

StarkMan — Sat, 10 Oct 2026 18:00:43 +0000

Internal certificate authorities fail on lifecycle, not on cryptography

The Monday morning outage that follows a certificate expiry is almost never a cryptographic failure. It is an ownership failure. A RADIUS certificate on a Wi-Fi authentication server expires over a weekend, nobody knows it exists, and the first shift cannot connect.

Why internal PKI drifts

Public certificate rules do not constrain internal PKI. The CA/B Forum timeline that shortens public TLS validity toward 47 days by 2029 applies to publicly trusted certificates, and internal PKI is explicitly outside it. An organisation can therefore set its own validity periods and its own verification policy. That freedom is also where the trouble starts, because nothing forces internal certificate inventories to exist.
Certificate sprawl follows from normal engineering practice. Network engineers own RADIUS and VPN certificates. Identity teams own SAML and OIDC signing certificates. Application teams issue TLS certificates through cloud platforms or CI pipelines. IT administrators deploy device enrolment certificates from an endpoint management system. Each team operates sensibly in isolation, and the result is an estate where nobody holds the complete picture.
An internal CA inherits a second dependency that public CAs do not create: the trust store. Every client that trusts the internal root must be updated when the root changes. That population includes operating systems, browser stores, appliances, embedded devices and third-party services, and it is frequently larger than the team that runs the CA believes.

The failure modes that recur

Three failure modes account for most of the incident reports.
The first is the invisible certificate. The inventory is incomplete, so the first sign of the problem is a service going down rather than a renewal ticket. RADIUS, VPN, SAML signing and device enrolment certificates are the usual candidates because they sit with teams that do not think of themselves as PKI operators.
The second is renewal that stops at the CA. A new certificate is issued and installed on the server, but the service is not reloaded, or the full chain is not deployed, or the private key does not match. The CA reports success and the service stays offline. This is why renewal, rotation and revocation belong in one operational workflow instead of separate tickets. Renewal replaces an expiring certificate, rotation normally generates a new key so the old one does not persist, and revocation handles compromise or policy-driven invalidation.
The third is trust store lag. A root or intermediate change requires every relying client to receive the new chain, and the rollover window has to be long enough for that distribution to complete. Guidance for private CA hierarchies puts subordinate CA validity at two to five times the lifetime of the certificates it issues, and recommends a long root lifetime, precisely to keep these transitions infrequent.

Structure that reduces the risk

Pick validity periods by working backwards from the endpoints. A short leaf lifetime limits exposure if a private key is lost, and it also means more renewals, and a missed renewal is an outage. The published default for private endpoint certificates is around thirteen months, with subordinate CA lifetimes measured in years. Organisations should pick a value deliberately instead of inheriting a default.
Plan root changes as a programme. Replacing a root affects the whole PKI and every relying trust store, so the practical approach is replacement rather than extension: create a successor CA, issue from it, distribute the new root alongside the old, monitor the transition milestones, then disable the predecessor once its certificates have expired. Naming the generations explicitly, such as a G2 suffix, avoids confusion during the overlap.
Automate the leaf, control the root. Automated issuance and renewal for service certificates removes the most common failure mode. Root changes should stay under human approval with a published schedule.
Instrument the inventory as a control. Every certificate record needs an owner, a service dependency list and an expiry date, and the CA should log issuance and revocation through the platform audit trail so that actions are attributable. A monitoring rule that fires at thirty days beats a spreadsheet reviewed quarterly.
Keep revocation honest. An internal CA that has no CRL or OCSP distribution path cannot revoke anything quickly, and OCSP carries its own operational cost because every validation becomes a network call to the responder. Revocation is only meaningful if relying clients actually check.

Limitations

None of this removes the underlying difficulty. Internal PKI governance spans teams with different priorities, and the team running the CA rarely controls the clients that must trust it. Automated renewal reduces missed renewals but introduces automation credentials and pipeline dependencies that then need their own protection. A very short leaf lifetime without automation turns an availability risk into an inevitability.

Defensive implications

Start with an inventory that names an owner for every certificate and every trust store entry, then make expiry a monitored event rather than a documented one, then automate leaf renewal and keep root rotation under a scheduled change process. Treat the trust store population as part of the PKI scope, because it is what makes root rotation expensive, and expensive rotations are the ones that get postponed.

References

Managing private CA lifecycle: https://docs.aws.amazon.com/privateca/latest/userguide/ca-lifecycle.html
AWS Private CA best practices: https://docs.aws.amazon.com/privateca/latest/userguide/ca-best-practices.html
Rotating CA certificates: https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-rotating-ca-certificates
Preparing for shorter public TLS validity: https://www.globalsign.cn/blog_detailed_303
Practical certificate lifecycle guide: https://www.purple.ai/blogs/zertifikate-richtig-verwalten-ein-praktischer-leitfaden-fur-den-lebenszyklus

What a database port count does and does not tell you

StarkMan — Sat, 10 Oct 2026 16:20:44 +0000

What a database port count does and does not tell you

Security reports about exposed databases usually open with a large number. The number is accurate and the conclusion drawn from it is often wrong. A measurement of a listening service describes a reachable socket, while the risk people associate with that sentence concerns unauthenticated data access. Those are different claims, and a measurement platform such as ZoomEye is built to separate them.

Context and method

The figures below come from ZoomEye searches executed against the global index. Each query asked for a single page of one result so the response carried a total count, and each was run once at collection time. The scope covers assets and websites that ZoomEye has observed, so the values are match counts within that corpus rather than a census of the internet.
| Query | Reported matches |
| --- | ---: |
| port="3306" | 24,564,355 |
| port="6379" | 4,944,933 |
| port="5432" | 4,701,115 |
| port="27017" | 1,680,408 |
The queries are available as saved searches: MySQL on 3306, Redis on 6379, PostgreSQL on 5432 and MongoDB on 27017.

Analysis

The port field records that the port answered. It does not record authentication state, database version, whether the listener accepts remote connections, or which data the instance holds. An instance behind a firewall that answers a probe from the scanning infrastructure but not from an arbitrary client still appears in the count.
That distinction changes how the numbers should be read. Twenty-four million observed MySQL ports is a statement about deployment patterns, and the difference between the Redis and MongoDB counts reflects how popular each default port is rather than how many instances are unprotected.
Comparisons inside one dataset remain useful. Querying the same field across regions, or the same port against an application fingerprint, shows how exposure is distributed and where a specific technology concentrates. Adding a country filter narrows the view without changing what the underlying field means.

Implications for defenders

Start from the count to decide what to inventory, then answer the harder question with your own configuration data. An asset inventory that records listening addresses, database versions and authentication requirements gives an actionable list, while a global match count cannot name a single host you own.
ZoomEye is a reasonable first step for that inventory when an organisation does not know which of its addresses are visible from the outside. Searching for the organisation's own ranges, certificate names or registers turns an internet-wide count into a scoped one, and the saved query can be re-run to see whether exposure changes after a firewall or binding change.
Limits deserve as much attention as the numbers. A count is a snapshot that moves as assets appear and disappear, matching behaviour depends on what the platform has probed, and no count establishes that any specific instance is vulnerable or that data was accessed. A large number is a prompt to check, a small number is not a clean bill of health.

References

[1] ZoomEye saved search, MySQL default port: https://www.zoomeye.ai/searchResult?q=cG9ydD0iMzMwNiI%3D
[2] ZoomEye saved search, Redis default port: https://www.zoomeye.ai/searchResult?q=cG9ydD0iNjM3OSI%3D
[3] ZoomEye saved search, PostgreSQL default port: https://www.zoomeye.ai/searchResult?q=cG9ydD0iNTQzMiI%3D
[4] ZoomEye saved search, MongoDB default port: https://www.zoomeye.ai/searchResult?q=cG9ydD0iMjcwMTci

Why API Gateways Keep Failing Authentication: Lessons From Cisco ISE CVE-2026-76460

StarkMan — Sat, 10 Oct 2026 11:20:42 +0000

Why API Gateways Keep Failing Authentication: Lessons From Cisco ISE CVE-2026-76460

A maximum severity score is rare enough to draw attention, and CVE-2026-76460 earned it. The flaw in Cisco Identity Services Engine combined unauthenticated access, remote exploitation and root-level command execution, and it exposed a pattern that shows up repeatedly in gateway-fronted APIs.

What the flaw allowed

CVE-2026-76460 is insufficient authentication control on an API endpoint, classified as CWE-648, incorrect use of privileged APIs. Cisco rated it CVSS 10.0. An unauthenticated remote attacker could send a crafted request to a management API endpoint and bypass the authentication of the web management interface, reaching root privileges on the device.
The affected products were Cisco ISE and Cisco ISE Passive Identity Connector in all configurations. Cisco fixed the issue in 3.1 patch 12, 3.2 patch 11, 3.3 patch 12, 3.4 patch 7 and 3.5 patch 4, depending on the major version in use.

The gateway model and its blind spot

ISE management exposes two interfaces: a web console and a REST API used by automation, monitoring and orchestration tooling. That API runs behind a gateway component derived from Kong, visible in logs as ise-kong. Requests to the management API pass through the gateway, which performs credential checks before forwarding traffic to backend services.
The centralized approach has a real benefit. Authentication lives in one place instead of being reimplemented by each backend service. It also concentrates risk: if a route in the gateway is not covered by an authentication plugin, that route is open, and backend services have no independent way to tell that the front door was unlocked.
Analysis of the advisory notes that Cisco did not name the specific endpoint or publish the crafted request. The same analysis points to gateway route coverage as the likely area rather than a backend login defect, based on the diagnostic guidance pointing at the gateway access log and the deliberately generic wording of the advisory. That reading is a reasoned inference, not a vendor statement, and it should be treated as such.

Exploitation timeline

Cisco disclosed the flaw on September 16, 2026, in advisory cisco-sa-ISE-ABP-VNSW7Tn5, noting that it was found while handling a support case, which implies a real deployment was already affected before publication. CISA added CVE-2026-76460 to the Known Exploited Vulnerabilities catalog the same day and set a remediation deadline of September 19, giving federal agencies 72 hours.
That short window reflects the current federal directive that replaced the older framework, under which the most dangerous entries receive deadlines measured in days. The directive also places forensic investigation ahead of patching for confirmed exploitation.

Remediation and investigation

Apply the appropriate ISE patch for the deployed major version. Because the flaw does not depend on configuration, narrowing the API surface is not a substitute for upgrading, though restricting who can reach the management interface remains worthwhile.
Review gateway access logs for requests to management API paths from unexpected sources, particularly requests that returned success while carrying unfamiliar usernames or automation user agents. Preserve logs before upgrading so that the investigation is not cut short by the deployment itself.

The broader lesson

Cisco is not alone in this failure mode. Any architecture that centralizes authentication at a proxy assumes complete and correct coverage of every route. That assumption is testable, and it deserves periodic verification rather than trust: enumerate the routes, confirm each one enforces authentication, and prove it with an unauthenticated request that is expected to fail.

References

Cisco advisory cisco-sa-ISE-ABP-VNSW7Tn5 (referenced through the reporting below)
InfoSec Write-ups / FreeBuf analysis of CVE-2026-76460: https://m.freebuf.com/articles/vuls/501736.html
NetEase report on the Cisco ISE patch: https://m.163.com/dy/article/L759MM2N05118UGF.html
CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Build Agents and Developer Workstations: The Docker Bind That Leaks Into Production

StarkMan — Sat, 10 Oct 2026 10:40:42 +0000

Build Agents and Developer Workstations: The Docker Bind That Leaks Into Production

The CARBONATO advisory is written for organisations operating Docker environments. In practice, a large share of the exposed Docker daemons on the Internet is unlikely to sit in production. Many sit on build servers, lab machines and developer workstations, places where the ports were opened for convenience and never closed.
That pattern is worth examining because it changes the response. The advisory's recommendations concern Docker hosts generally, and they apply to a continuous integration runner exactly as they apply to a production node.
A developer machine usually becomes reachable for mundane reasons. Docker's Remote API is convenient for tooling, so the daemon is configured to listen on a network address. On a cloud network with a permissive security group, or behind a home router with a forwarded port, that listener is reachable from outside. Nothing announces the setup in application logs, because the daemon that answers is behaving normally.
An external measurement cannot separate the two roles, and it should not be expected to:

app="Docker" && port="2375"                          -> 1,032 assets globally

That query was executed on 30 September 2026 at 17:17 UTC with sub_type=all. It returns assets with a Docker fingerprint on the conventional unauthenticated remote API port, without indicating whether each is production infrastructure, a build runner or a laptop. ZoomEye reports what the service presents, not what the organisation intended it to be.
An inventory produced from this query therefore has to be classified internally before it becomes a remediation plan. That step is cheap with a machine registry and painful without one, which is itself worth recording.
There is a second, sharper consequence for build infrastructure. A CI runner frequently holds deploy credentials, registry tokens and signing keys, because its job is to publish artifacts. The advisory's containment advice is explicit about that situation: if compromise is suspected or confirmed, identify and rotate credentials accessible from affected systems, including API keys, access tokens and SSH keys. A build runner at the top of the exposed list is therefore a higher-value item than its production or non-production label suggests.
The advisory also notes that the campaign scans outward from compromised hosts for other Docker daemons exposed on 2375. A build network that hosts several engine endpoints is exactly the environment that behaviour would traverse, so monitoring for unusual scanning from build subnets is a reasonable control to add alongside the exposure review.
None of this requires treating developer environments as untrusted. It requires deciding which machines can be reached from outside at all, recording the decision, and re-checking it when infrastructure moves. The external query supplies the second half of that comparison; the first half exists only inside the organisation.

References

CSA / SingCERT, "Advisory on CARBONATO Botnet Campaign Targeting Exposed Docker Daemons", 30 September 2026: https://www.csa.gov.sg/alerts-and-advisories/advisories/ad-2026-012
Docker, "Protect the Docker daemon socket": https://docs.docker.com/engine/security/protect-access/
ZoomEye query app="Docker" && port="2375", sub_type=all, executed 2026-09-30T17:17:22Z, 1,032 assets.

SNI, Host headers and the limits of name-based virtual hosting: CVE-2026-102795 explained

StarkMan — Sat, 10 Oct 2026 06:40:41 +0000

SNI, Host headers and the limits of name-based virtual hosting: CVE-2026-102795 explained

Overview

On 2 October 2026 the Apache Software Foundation published CVE-2026-102795 for Apache Traffic Server. The affected versions are 9.0.0 through 9.2.14 and 10.0.0 through 10.1.3; 9.2.15 and 10.1.4 contain the fix. The advisory describes an improper access control weakness in which a "SNI to Host header matching policy is not properly enforced".

Background: two ways of naming a site

Name-based virtual hosting in a TLS-terminating proxy depends on two separate pieces of information.
The SNI extension is presented during the handshake. It is not encrypted in a standard TLS 1.2 or TLS 1.3 handshake, and it is chosen by the client. The listener uses it to select a certificate and, usually, a configuration context.
The Host header is presented inside the HTTP request, after the secure channel exists. It is also chosen by the client.
Neither value is authoritative on its own. Their combined value comes from the expectation that a well-behaved client sends the same name in both places, and from the proxy's decision to reject requests where that expectation is violated. CVE-2026-102795 concerns that rejection step.

Mechanism and exploitation conditions

The published description is short and does not include a request-level walkthrough. What can be said with confidence is the precondition: the proxy must be expected to compare an SNI value with a Host value, and the client must be able to choose them independently. That situation arises in shared edges that serve multiple names.
Apache has not reported exploitation in the wild, and no public proof of concept is confirmed at the time of writing. Descriptions of this flaw should not be upgraded into claims of remote code execution.

Affected products and scope

All 9.x releases before 9.2.15 and all 10.x releases through 10.1.3 are affected. The record also supersedes CVE-2026-41920, which described the same weakness but with an incorrect version range and a misleading fix version.

Exposure context

ZoomEye matched 311,469 assets for app="Apache Traffic Server" on 3 October 2026. The companion query vul.cve="CVE-2026-102795" returned 0, which is typical immediately after disclosure. A fingerprint count measures where the software is visible; it does not measure which version each instance runs.

Remediation and mitigations

Upgrade to 9.2.15 or 10.1.4. Beyond the upgrade, the durable improvement is to reduce the number of names any single edge is willing to serve: explicit virtual hosts rather than catch-alls, a refusal as the default outcome for an unrecognised name, and a periodic review of which names are still expected to resolve.

References

SecurityOnline reporting on the Apache advisory batch, 3 October 2026
Apache Traffic Server download and release information

Cloud IAM: Reading a Policy Before You Trust It

StarkMan — Fri, 09 Oct 2026 18:00:41 +0000

Cloud IAM: Reading a Policy Before You Trust It

Cloud permissions are granted through policies, and the difference between a working policy and a dangerous one is often a single wildcard.

Three things a policy states

Every policy answers three questions: which principal, which action and which resource, optionally constrained by conditions. Reviewing a policy means reading those four elements together rather than scanning for the word *.

The wildcard patterns worth searching for

A wildcard action such as s3:* combined with a wildcard resource grants every operation on every object in the account. An action list that includes iam:PassRole next to a broad compute permission allows a principal to hand an over-privileged role to a service it controls, which is a privilege escalation path rather than a simple permission.
A wildcard principal combined with an allow effect on a data resource is a public grant. That combination appears in storage policies far more often than teams expect.

Controls that limit blast radius

Permissions boundaries cap the maximum permissions an identity policy can grant, so a delegated administrator cannot escalate beyond the boundary. Access Analyzer identifies resources shared with external entities and policies that grant unused permissions.
The IAM Access Advisor data, which records the last time a service was used, turns the least-privilege conversation from a guess into a sequence of concrete removals.

A maintainable process

Treat policy change as a reviewed change. Generate permission sets from observed usage, remove unused grants on a schedule, and alert on the creation of wildcard administrative policies. Centralised root and break-glass identities should be monitored separately from ordinary accounts, because a change there is always meaningful.

References

AWS documentation, Security best practices in IAM: https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html
AWS documentation, IAM Access Analyzer: https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html
Microsoft Learn, Best practices for Azure RBAC: https://learn.microsoft.com/en-us/azure/role-based-access-control/best-practices

CVE-2026-100727: unauthenticated file read in GROWI's local upload mode

StarkMan — Fri, 09 Oct 2026 17:40:40 +0000

CVE-2026-100727: unauthenticated file read in GROWI's local upload mode

GROWI, the wiki and collaboration platform published by GROWI, Inc., received a security fix in version 7.5.5 on October 5, 2026. The release closes CVE-2026-100727, an access-control defect that lets an unauthenticated visitor read files kept by pages the platform does not expose publicly. The defect applies to deployments that store uploads with the local file system option.

Vulnerability overview

Japan's JVN published the coordinated advisory as JVN#24352487 on 2026/10/05. JPCERT/CC coordinated the report, and JVN credits GROWI, Inc. as the reporter. The weakness is recorded as CWE-552, Files or Directories Accessible to External Parties. The advisory lists two scoring vectors:

CVSS 4.0: AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N, base score 6.9
CVSS 3.0: AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N, base score 5.3 Both describe one situation. The attacker reaches the service over the network, holds no account, and needs no user interaction, while the resulting impact stays inside confidentiality. Integrity and availability are untouched, so this is a disclosure bug rather than a route to remote code execution.

Mechanism and exploitation conditions

GROWI builds file upload on a configurable storage backend. Administrators decide where attachments live when they configure the instance, and the advisory focuses on the case where that choice is the local option. Under that arrangement the application writes uploaded content into directories it owns and serves the content back to readers.
The defect is that reachability of a stored object follows the location of the file instead of the permission check attached to the page that references it. A remote unauthenticated attacker can request files belonging to non-public pages and receive their contents. Two conditions must hold at the same time for a deployment to be exposed:

GROWI runs a version earlier than 7.5.5
The file upload setting is configured as "Local" An instance that keeps uploads in an external storage backend does not match the affected configuration the advisory describes.

Impact

The attacker gains read access to files the operator never published. On a wiki, those objects are often attachments on draft pages, internal runbooks, meeting notes, scanned contracts, or exported configuration. The advisory scores confidentiality only, and that matches the outcome: no write primitive, no execution primitive, and no authenticated session required.
The missing login requirement changes the operational picture. Many access-control bugs need a valid low-privilege account, which at least leaves an audit trail tied to a known identity. Here the request can arrive anonymously, so the useful question after detection is which files were reachable and for how long.

Affected products and scope

The advisory names GROWI versions prior to v7.5.5 and notes that exposure depends on the "Local" upload setting. It does not enumerate individual page-level configurations beyond that. Operators should treat the version as the first filter and the storage configuration as the second. A deployment on an older release that uses an external upload backend falls outside this specific CVE even though its version number sits below the fix.

Exposure context

A ZoomEye query for hosts whose HTML title contains the product name returned 401 records, collected on 2026-10-05:
Search Dork: title="GROWI"
That figure counts assets that identify themselves as GROWI through the page title. It does not show that any of them run a vulnerable version, and it says nothing about which upload backend each one uses. Treat the number as a starting inventory for verification rather than a count of confirmed vulnerable hosts.

Remediation and mitigations

Update to GROWI v7.5.5. After the instance reports the new version, re-check the attachment settings that were in place before the upgrade and confirm that pages which previously exposed files can no longer be reached without a session. Where an immediate upgrade is not possible, the effective short-term control is to move uploads off the local backend, because the affected code path is the one tied to that setting.
Two follow-up checks are worth running after patching. Review which non-public pages held attachments during the exposure window, since the advisory offers no reliable way to tell whether a read occurred. Rotate any credential or token that was stored as an attachment on those pages, because a read of that object is indistinguishable from a read by its owner.

References

OpenWrt: 2,317,463 Fingerprint Matches Where the Home Router Becomes the Edge

StarkMan — Fri, 09 Oct 2026 16:00:39 +0000

OpenWrt: 2,317,463 Fingerprint Matches Where the Home Router Becomes the Edge

The count

ZoomEye returns 2,317,463 matches for app="OpenWrt", collected on 2026-09-24. The fingerprint identifies the web interface of the OpenWrt router firmware, an open source distribution that runs on consumer routers, travel devices and, in many organizations, the routers in remote offices and home offices.
The count describes services presenting that signature. No authentication was attempted against any address.

The device that is the perimeter now

Remote work moved the network edge into places the security team does not control. A router in a home office is the boundary between an employee's devices and the corporate services they reach over a tunnel, and it is administered by the person who lives there.
An OpenWrt device in that position is capable of a lot: it forwards traffic, it can terminate a tunnel, it can run an ad-blocking or DNS service that sees every lookup, and it can host packages installed from a repository. Its administration interface is therefore an edge control point with home-network change management.

Why the exposure happens

Remote access on these devices is enabled for the same reasons it is enabled on a small business NAS: the administrator wants to reach the interface from outside, and the simplest way involves publishing a port or using a dynamic DNS name. Firmware on consumer hardware is also updated on the owner's schedule, and that schedule is often very long.

What the organization can control

The controls that hold up do not depend on the device being well administered. Require a managed tunnel client on employee devices so that traffic to corporate services does not depend on the home router's integrity. Treat the home network as untrusted in the access policy, which means device posture checks and per-application authorization rather than network-level trust.
Where the organization supplies the router, treat it as managed equipment with a defined firmware baseline, a documented configuration and remote administration over the tunnel rather than a published management port. An inventory of those devices is also an inventory of the addresses that answer from outside.

Reading the count as an inventory tool

The value of the fingerprint for an enterprise is not the global number. It is the ability to ask whether any address the organization owns presents the signature, which turns a category of unmanaged equipment into a list that can be reviewed.

Implications

The perimeter has been distributed for years, and the tools for managing a distributed perimeter are inventory, posture and tunneling rather than firewall rules. An exposure fingerprint answers the inventory question for one popular firmware platform, and the same pattern can be applied to the other devices sitting between an employee and the corporate network.

References

ZoomEye search for app="OpenWrt": https://www.zoomeye.ai/
OpenWrt firewall documentation: https://openwrt.org/docs/guide-user/firewall/start

17,884 Artifactory Matches and 400 Title Matches: Why Query Choice Changes the Answer

StarkMan — Fri, 09 Oct 2026 11:00:39 +0000

17,884 Artifactory Matches and 400 Title Matches: Why Query Choice Changes the Answer

Two queries for the same product, run at the same time, returned numbers that differ by a factor of roughly 45. Neither is wrong. Understanding why they differ is the difference between using an exposure tool and being misled by one.

The context

JFrog Artifactory is a software supply chain chokepoint. It holds the packages, container images and dependencies that build pipelines resolve. Three vulnerabilities were chained in observed attacks during August and September 2026: CVE-2026-82329 (improper authentication, CVSS 9.8), CVE-2026-42018 (anonymous token exposure, CVSS 7.5) and CVE-2026-42016 (incorrect authorization, CVSS 8.1). CISA added JFrog entries to KEV on 12 September 2026.

The queries and their results

Query	Matches
`app="JFrog Artifactory"`	17,884
`title="Artifactory"`	400

The difference is large enough to be confusing, so it is worth explaining what each query actually measures.

The app query relies on ZoomEye's product fingerprinting, which identifies software through a combination of response characteristics rather than a single visible string. Artifactory exposes distinctive API endpoints, response headers and error formats, so a fingerprint can match even when the page title does not contain the product name.

The title query matches only pages whose HTML title contains the literal string. Many Artifactory deployments sit behind custom reverse proxies, use a branded login page, or return a title that names the organisation rather than the product. Those instances are invisible to the title query and visible to the fingerprint.

Which number to use

For exposure assessment, the fingerprint query is the more useful starting point, because it is designed to identify the software rather than a string. But the 17,884 figure carries its own caveats:

Fingerprint matching has false positives. A reverse proxy or a documentation mirror may present characteristics that resemble the product.
Version is not part of the query. The fixed version for the CVE-2026-82329 branch is 7.161.20; the broader fixed release is 7.133.11. Matched instances may be patched.
Reachability is not exploitability. Artifactory instances are frequently placed behind authentication gateways or restricted to internal networks, even when a service is detected.
Repository deployments are often internal. The public count is a lower bound on total deployment, not an upper bound on risk.

Why this matters for supply chain risk

The distinguishing feature of an artifact repository is its position downstream of nothing and upstream of everything. An attacker who controls it can replace cached packages and abuse publishing credentials, which means the affected systems include every build that pulls from it.

That makes the exposure question different from a typical web application. For most software, the question is whether an instance is reachable. For a repository, the question is also whether the artifacts it serves can be trusted, which is a question no external scan can answer.

A practical method

Use the fingerprint query as the discovery baseline. app="JFrog Artifactory" is the more complete signal.
Do not treat the title count as a contradiction. It measures a narrower thing.
Verify version against 7.133.11 and 7.161.20 on instances you own.
Check for the artifacts of the observed attack. Malicious plugins, unfamiliar administrator accounts and SSH keys attached to accounts that should not have them.
Verify artifact integrity independently. Compare hashes and signatures on production images and build outputs. This is the control that addresses the supply chain consequence rather than the exposure.

The general lesson

Different queries answer different questions. A fingerprint query asks "is this software here." A title query asks "does this page say this word." When the two disagree by a large margin, the disagreement is information: it tells you that the product is frequently deployed in ways that hide its identity, which is itself a relevant fact about how it is operated.

References

ZoomEye search results for app="JFrog Artifactory" (17,884) and title="Artifactory" (400), collected 23 September 2026
JFrog security advisories for CVE-2026-82329, CVE-2026-42016 and CVE-2026-42018
NVD entries for the three CVEs
CISA Known Exploited Vulnerabilities Catalog, JFrog entries added 12 September 2026

DEV Community: StarkMan

3,121 Owncast Servers: Security When the Application Is Meant to Be Public

The count

The public-by-design problem

What a compromised stream server means

Hardening

Using the measurement

References

McKesson, ShinyHunters and the Vishing Path Through Okta Into Salesforce and Snowflake

McKesson, ShinyHunters and the Vishing Path Through Okta Into Salesforce and Snowflake

No exploit was involved

What was reached, and what was taken

What McKesson confirmed

The infrastructure behind the phishing

The warning that came first

What actually reduces this risk

References

A Date Filter Is Not an Install Date: Reading Time-Bounded Exposure Queries

A Date Filter Is Not an Install Date: Reading Time-Bounded Exposure Queries

Bounding the observation

What after refers to

The honest use of a time filter

Practical next steps

Limitations

References

Internal certificate authorities fail on lifecycle, not on cryptography

Internal certificate authorities fail on lifecycle, not on cryptography

Why internal PKI drifts

The failure modes that recur

Structure that reduces the risk

Limitations

Defensive implications

References

What a database port count does and does not tell you

What a database port count does and does not tell you

Context and method

Analysis

Implications for defenders

References

Why API Gateways Keep Failing Authentication: Lessons From Cisco ISE CVE-2026-76460

Why API Gateways Keep Failing Authentication: Lessons From Cisco ISE CVE-2026-76460

What the flaw allowed

The gateway model and its blind spot

Exploitation timeline

Remediation and investigation

The broader lesson

References

Build Agents and Developer Workstations: The Docker Bind That Leaks Into Production

Build Agents and Developer Workstations: The Docker Bind That Leaks Into Production

References

SNI, Host headers and the limits of name-based virtual hosting: CVE-2026-102795 explained

SNI, Host headers and the limits of name-based virtual hosting: CVE-2026-102795 explained

Overview

Background: two ways of naming a site

Mechanism and exploitation conditions

Affected products and scope

Exposure context

Remediation and mitigations

References

Cloud IAM: Reading a Policy Before You Trust It

Cloud IAM: Reading a Policy Before You Trust It

Three things a policy states

The wildcard patterns worth searching for

Controls that limit blast radius

A maintainable process

References

CVE-2026-100727: unauthenticated file read in GROWI's local upload mode

CVE-2026-100727: unauthenticated file read in GROWI's local upload mode

Vulnerability overview

Mechanism and exploitation conditions

Impact

Affected products and scope

Exposure context

Remediation and mitigations

References

OpenWrt: 2,317,463 Fingerprint Matches Where the Home Router Becomes the Edge

OpenWrt: 2,317,463 Fingerprint Matches Where the Home Router Becomes the Edge

The count

The device that is the perimeter now

Why the exposure happens

What `after` refers to