DEV Community: OnaEiuspkz

Stolen OAuth Tokens Outlive Password Resets: Hardening Session Material in SaaS Estates

OnaEiuspkz — Wed, 16 Sep 2026 16:36:55 +0000

Stolen OAuth Tokens Outlive Password Resets: Hardening Session Material in SaaS Estates

When an attacker steals a password, you reset it. When an attacker steals a refresh token, a password reset does not necessarily help, and many incident responders discover this at the worst possible moment. Session material has become the preferred credential in SaaS environments because it is portable, long-lived and rarely inventoried.

Why the reader needs this

Modern SaaS access is a chain of tokens: an identity provider issues an access token and a refresh token, the client stores them, and downstream applications accept them without re-checking the user. If a token is exfiltrated from a browser profile, a CI secret, a logging pipeline or a compromised laptop, it can be replayed from anywhere the issuer accepts. The account owner may see nothing unusual, because the session is legitimate from the provider's perspective.

Technical context: which artifacts survive what

Different credential artifacts have different lifetimes and different remediation paths:

Access tokens are typically short-lived, often under an hour. Revoking them is time-bounded and mostly automatic.
Refresh tokens are the durable artifact. They can be valid for days or months, and they are what allows an attacker to mint new access tokens after the original expires.
Session cookies for browser-based single sign-on can persist for weeks if the provider allows long sessions, and they may be bound to nothing more than a cookie value.
Service account keys and client secrets never expire unless someone rotates them, and they are frequently pasted into CI variables, wikis and chat messages. The critical asymmetry is that password reset invalidates a password, not necessarily a token. Providers differ in whether a password change revokes existing refresh tokens, and in whether an administrator can enumerate and revoke sessions for a user. ## A concrete failure chain This chain is a composition of publicly documented token-theft patterns, presented as a reasoning model rather than a specific incident report.
An attacker obtains a refresh token, through infostealer malware on an employee laptop, a misconfigured log that captured an authorization header, or a leaked CI secret.
The attacker exchanges the refresh token for a new access token from the legitimate identity provider.
No password is used, so no password-based anomaly detection fires.
The attacker enumerates the SaaS estate using the token: mail, file storage, source control, depending on granted scopes.
The victim detects the intrusion and resets the password. The refresh token remains valid, so the attacker continues. The window between detection and actual containment is where the damage accumulates, and it is determined by whether the responder knows to revoke tokens rather than just credentials. ## Defensive implications Know your revocation surface. Before an incident, document for each identity provider whether an administrator can list active sessions and revoke refresh tokens, and whether a password change does so automatically. This is a five-minute question with a multi-day answer during an incident. Bind tokens to something. Token binding, sender-constrained tokens such as DPoP, or certificate-bound tokens make a stolen token useless without the corresponding key. Where the provider supports it, this converts token theft from a full account compromise into a failed request. Shorten refresh token lifetime and rotate. Rotation with reuse detection means a stolen token that is used after the legitimate client refreshes it triggers an alert and invalidates the family. Inventory non-human credentials. Service account keys and client secrets should have owners, expiry dates and a rotation schedule. An unrotated key is a permanent credential. Detect replay, not just login. Alert on the same refresh token being used from two geographies, on token exchanges from unexpected user agents, and on first-time access to sensitive scopes. Login-based detection misses this entirely. Reduce scope by default. A token that can read mail and write files is worth more to an attacker than one that can only read a calendar. Request the narrowest scope the integration needs. ## Limits of this analysis Token binding requires client support and is not universally available. Rotation can break poorly written integrations that assume a refresh token is permanent, so it must be tested. Session revocation tooling varies widely between providers, and in some cases the only reliable containment is to disable the account and re-enroll the user. These constraints are the reason token hygiene is an architectural problem rather than a checkbox. ## References
OAuth 2.0 Security Best Current Practice (RFC 9700): https://www.rfc-editor.org/rfc/rfc9700.html
OAuth 2.0 Demonstrating Proof of Possession (DPoP), RFC 9449: https://www.rfc-editor.org/rfc/rfc9449.html
OAuth 2.0 Token Revocation, RFC 7009: https://www.rfc-editor.org/rfc/rfc7009.html
MITRE ATT&CK, Steal Application Access Token (T1528): https://attack.mitre.org/techniques/T1528/

Binding to 0.0.0.0: the design decision behind CVE-2026-87827

OnaEiuspkz — Wed, 16 Sep 2026 16:30:35 +0000

Binding to 0.0.0.0: the design decision behind CVE-2026-87827

Vulnerability overview

CVE-2026-87827 is a 10.0-rated command execution flaw in KGUARD DVR firmware, reported by Netlab 360. What makes it worth studying beyond its severity score is how small the root cause is. The vulnerable service was written to accept commands from anyone, and it was configured to accept them on every network interface. Both choices are common in embedded firmware, and together they turn a convenience feature into a remotely exploitable backdoor.

Mechanism and exploitation conditions

The service in question listens on a network port, binds to 0.0.0.0, and executes the commands it receives without authentication. Netlab 360's advisory states it can "remotely execute system commands without authentication." Binding to 0.0.0.0 means the socket is not limited to the loopback interface or to a single internal address, so any host that can route packets to the device can reach the service.
Exploitation is therefore a matter of network access. No credentials are involved, and no user interaction is required. The researchers withheld the port number to make automated exploitation harder. Firmware released after 2017 changes the bind address to 127.0.0.1, which is the same service restricted to local callers. That one-line change is the entire fix.

Impact

An attacker with command execution on a DVR can install persistent malware, pivot to other hosts on the same network, or add the device to a denial-of-service botnet. The last outcome has already occurred. Mirai_ptea (Rimasuta) and Mirai_aurora incorporated the exploit, and some RapperBot variants reused it in 2026. Because DVRs are rarely patched and rarely monitored, a compromised unit can remain in a botnet for years.

Affected products and scope

The vulnerable firmware dates from 2016. Affected models include D1004NR, D1008NR, D1016NR, D1104, D1108NR, D1116NR, and the D99xx variants. Netlab 360 estimated at least 3,000 exposed devices still online, a figure based on its own reachability scanning.

Exposure context

ZoomEye returned 864,518 assets for app="KGUARD DVR" on 2026-09-16. The count reflects devices whose fingerprint matches the product, not devices confirmed to run vulnerable firmware or to expose the affected port. It is a measure of deployment scale on reachable networks. The distance between that number and Netlab's 3,000 estimate suggests that most reachable units already run firmware with the loopback binding.

Remediation and mitigations

Apply firmware released after 2017, which binds the service to 127.0.0.1 and removes remote reachability. If no update exists for a given model, block inbound access to the management port at the network edge and segment the recorder away from critical systems. Outbound monitoring remains useful, since a device that has joined a botnet will begin connecting to command-and-control infrastructure that a healthy DVR never contacts.

References

CVE-2026-87827 (CVSS 10): KGUARD DVR Fully Compromised, SecurityOnline.info, https://securityonline.info/cve-2026-87827-kguard-dvr-mirai/
Netlab 360 advisory on the KGUARD DVR command execution flaw, https://blog.netlab.360.com/
ZoomEye search: app="KGUARD DVR", https://www.zoomeye.ai/searchResult?q=YXBwPSJLR1VBUkQgRFZSIg%3D%3D

mySCADA myPRO Manager: Two Missing-Authorization Flaws in an ICS Management Platform (Operational View)

OnaEiuspkz — Wed, 16 Sep 2026 09:25:16 +0000

Unauthenticated SMS and Privileged API Access in mySCADA myPRO Manager

Vulnerability overview

Two authorization defects in mySCADA myPRO Manager were disclosed in a CISA advisory: CVE-2026-73807 at CVSS 9.8 and CVE-2026-82567 at CVSS 6.3. Both are missing-authorization issues in a platform that operators use to manage industrial processes. mySCADA Technologies shipped fixes in version 2.2, and no exploitation has been confirmed publicly.

Mechanism and exploitation conditions

The two flaws share a root cause but sit in different components, which matters for defenders because blocking one does not block the other.
CVE-2026-73807 is in the command API. The advisory says the API "does not properly enforce authentication for privileged functions," meaning the authorization check that should gate management operations is absent or ineffective. An unauthenticated caller with network access reaches those operations directly.
CVE-2026-82567 is in the notification gateway. The gateway publishes an HTTP endpoint for sending SMS through a GSM modem, and that endpoint accepts requests without an authentication check. A crafted request with a message payload causes the modem to transmit.
Neither flaw needs a prior foothold. The attacker needs a route to the service, nothing more.

Impact

The command API flaw is the more damaging of the two. Privileged management functions on a SCADA platform control what operators can see and change, so unauthenticated access to them lets an attacker alter system state or blind the people responsible for running the plant.
The SMS flaw is narrower but has a practical use. Messages sent through the plant's own modem inherit the credibility of the operator's infrastructure. An attacker can push convincing text to maintenance staff or on-call engineers, and the operator pays for the traffic. In environments where SMS is still the alerting channel, that is a meaningful path for follow-on attacks.

Affected products and scope

All mySCADA myPRO Manager installations at version 2.1 or earlier are affected. Version 2.2 contains the fix. The advisory does not identify a deployment mode that avoids the vulnerable code paths.

Exposure context

ZoomEye reported 651 assets matching title="mySCADA" on 2026-09-16. This is a product-deployment signal, not a vulnerability count: the query matches the product's page title and says nothing about version or endpoint exposure. Treat it as a rough measure of how much of this product sits on reachable networks.

Remediation and mitigations

Move to version 2.2. If that is not possible in the current maintenance window, cut off network access to both the command API and the notification gateway. Segment the management interface so only trusted administrative hosts can reach it, and disable the SMS gateway when the site does not depend on it.
Watch for unauthenticated requests to management endpoints and for SMS traffic that no operator triggered. Both are visible in normal logging if the logs are retained.

References

SecurityOnline, "Critical mySCADA myPRO Manager Vulnerabilities Patched": https://securityonline.info/myscada-mypro-manager-vulnerabilities/
CISA ICS advisories: https://www.cisa.gov/news-events/ics-advisories
ZoomEye query title="mySCADA", executed 2026-09-16: https://www.zoomeye.ai/searchResult?q=dGl0bGU9Im15U0NBREEi

CVE-2026-48710 (BadHost): How a Malformed Host Header Bypasses Starlette Path Authorization

OnaEiuspkz — Wed, 16 Sep 2026 08:26:40 +0000

CVE-2026-48710 (BadHost): How a Malformed Host Header Bypasses Starlette Path Authorization

Vulnerability overview

CVE-2026-48710, tracked publicly as BadHost and catalogued by X41 D-Sec as X41-2026-002, is an authentication bypass in the Starlette ASGI framework. The flaw is CWE-444, inconsistent interpretation of HTTP requests. Starlette maintainers published a GitHub security advisory with a CVSS v3.1 base score of 6.5 (Medium), vector AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N. X41 D-Sec rated the practical risk higher, at 7.0, and argued that the score understates impact in AI tooling deployments. On 2026-09-02 CISA added CVE-2026-48710 to its Known Exploited Vulnerabilities catalog, citing evidence of active exploitation.

Mechanism and exploitation conditions

Starlette reconstructs request.url from the ASGI scope dictionary. Before version 1.0.1, that reconstruction concatenated the client-supplied Host header with the request path and re-parsed the result as a URL, without validating the Host value against RFC 9112 or RFC 3986. When the Host header contains URI delimiters such as /, ?, #, @, backslash, or a space, the re-parsed URL shifts the path boundary.
The result is a disagreement between two path sources inside one request:

The router dispatches on scope["path"], the raw request-target path.
Middleware that reads request.url.path sees the value produced by the polluted reconstruction. A request for /admin sent with Host: example.com/public?x= is routed to /admin, but request.url.path evaluates to /public. Any authorization middleware that decides on request.url.path — a path-prefix allowlist, for example — evaluates the attacker-influenced value while the router serves the real, protected endpoint. Exploitation requires a specific combination, not merely the presence of Starlette:
The application must rely on request.url or request.url.path for a security decision, most commonly a path-prefix allowlist or a public-path bypass list.
No reverse proxy, CDN, or API gateway in front of the application may already reject or normalize malformed Host values.
The application server must be reachable with an attacker-controlled Host header. Endpoints protected by FastAPI Depends() or Security() dependencies, or by business-layer permission checks, are not bypassed by path pollution alone, because those checks bind to the endpoint rather than to a reconstructed URL. ## Impact Successful exploitation yields unauthenticated access to endpoints the application intended to protect. X41 D-Sec demonstrated the transition from a 403 Forbidden response to 200 OK after adding a single character to the Host header. Because the bypass is a precondition rather than a terminal action, severity depends on what the reachable endpoint does. X41 D-Sec found multiple open-source projects whose security checks depend on the reconstructed URL, and warned that the flaw can chain from authentication bypass into server-side request forgery and, in some deployments, remote code execution. The LiteLLM case shows the chain concretely. Horizon3.ai reported that CVE-2026-48710 removes the authentication requirement from CVE-2026-42271, a command injection in LiteLLM's MCP test endpoints. Chained, the two flaws permit unauthenticated remote code execution on the LiteLLM host, exposing model provider credentials, proxy-stored API keys, and connected AI infrastructure. Horizon3.ai assessed the combined chain at CVSS 10.0. ## Affected products and scope
Starlette: versions from 0.8.3 up to and including 1.0.0 are affected. Version 1.0.1 is the fix.
Downstream frameworks: FastAPI depends on Starlette, so applications built on FastAPI inherit the flaw unless the underlying Starlette version is patched. vLLM, Text Generation Inference, LiteLLM, and many MCP server implementations sit on this stack.
LiteLLM: versions 1.74.2 through 1.83.6 ship the vulnerable MCP debug endpoints; 1.83.7 fixes the command injection but not the framework-level bypass. Version 1.84.0 or later addresses both. Scope follows code behaviour, not installation. An application that never imports Starlette directly can still be affected through a transitive dependency, and GitHub lists more than 400,000 dependent projects. Conversely, a Starlette application that never makes a security decision on request.url.path is not exploitable through this specific mechanism. ## Exposure context A ZoomEye query for http.body="Starlette" returned 1,249 matching assets at the time of writing. A narrower query combining http.header.server="uvicorn" with http.body="Starlette" returned 437 assets, and title="Starlette" returned 252. A CVE-specific query for vul.cve="CVE-2026-48710" returned 0, which reflects indexing coverage rather than absence of affected systems. These counts describe assets whose responses contain Starlette-related strings; they do not confirm that any specific host runs an affected version or exposes a bypassable authorization path, and they are not a count of confirmed vulnerable systems. ## Remediation and mitigations
Upgrade Starlette to 1.0.1 or later. This is the direct fix. The patch validates the Host header against a hostname pattern and falls back to the socket-level server address when the value is malformed.
Patch the full dependency tree, not just the top layer. Upgrading FastAPI alone does not necessarily raise the Starlette version. Inspect the resolved dependency tree and pin Starlette explicitly.
Update LiteLLM to 1.84.0 or later if it is deployed, and treat the MCP test endpoints as sensitive.
Stop using request.url.path for authorization. The advisory recommends binding checks to endpoints through Starlette requires() or FastAPI Depends() and Security(). Audit the codebase for request.url.path and str(request.url) used in access decisions.
Filter malformed Host headers at the edge. A reverse proxy, ingress controller, or WAF configured with a host allowlist that rejects /, ?, #, @, backslash, and space blocks the attack before it reaches the application. This is a mitigation, not a substitute for patching.
Validate exposure. X41 D-Sec published an online scanner at badhost.org, along with Semgrep rules and CodeQL queries, to identify affected code paths.
Rotate credentials if compromise is suspected. For AI gateways, that includes model provider keys and any tokens stored by the gateway. ## References
CISA, "CISA Adds Seven Known Exploited Vulnerabilities to Catalog," 2026-09-02: https://www.cisa.gov/news-events/alerts/2026/09/02/cisa-adds-seven-known-exploited-vulnerabilities-catalog
X41 D-Sec, BadHost advisory (X41-2026-002) and badhost.org scanner
Starlette GitHub security advisory for CVE-2026-48710, fixed in 1.0.1
Horizon3.ai analysis of the CVE-2026-48710 and CVE-2026-42271 chain
InfoQ, "BadHost vulnerability puts AI agents, evaluators and LLM gateways at risk"

The Advisory That Was Not a Patch: Reading AA26-231A and the AI-Assisted Reconnaissance of Siemens S7 PLCs

OnaEiuspkz — Wed, 16 Sep 2026 07:48:27 +0000

The Advisory That Was Not a Patch: Reading AA26-231A and the AI-Assisted Reconnaissance of Siemens S7 PLCs

On 2026-08-19, five U.S. federal agencies published a joint advisory warning that threat actors were conducting reconnaissance against Siemens S7 series programmable logic controllers. The detail that made headlines was the use of AI-generated exploitation scripts. The detail that matters more for defenders is that no new vulnerability was disclosed at all.

What the advisory actually says

Joint Cybersecurity Advisory AA26-231A was issued by the NSA, CISA, the FBI, the Department of Energy, and the Environmental Protection Agency. It describes actors using internet scanning services to locate internet-exposed or poorly protected PLCs running outdated software, then employing AI-generated exploitation scripts that incorporate the open-source snap7.dll and python-snap7 libraries while masquerading as legitimate monitoring tools.
Those scripts provide read and write access to PLC memory, configuration data, and ladder logic over the S7comm protocol, typically on TCP port 102. The advisory names the affected families broadly: all CPU variants of the S7-200, S7-300 (including 314, 315, and 317), S7-400, S7-1200 (CPU 1211C, 1212C, 1214C, 1215C, and 1217C), and S7-1500 series, including F-series safety controllers.
The agencies assess the activity as persistent reconnaissance intended to develop capabilities and prepare for potential operational effects. Sectors identified as most targeted are critical manufacturing, energy, water and wastewater, chemical, food and agriculture, and commercial facilities.

The part that is easy to misread

Siemens responded that AA26-231A does not describe a new vulnerability in the S7 series. The company characterized the advisory as identifying ways to exploit misconfigurations that its own guidance already addresses, and pointed customers to ProductCERT advisory SSB-104599 for current software, protected networks, strong passwords, and model-specific documentation.
This is an important distinction, and it cuts against the instinct to wait for a patch. There is no single update that eliminates the threat described in AA26-231A. The advisory explicitly refers to "known vulnerabilities, misconfigurations, and other weaknesses" rather than a shared defect across the product line. Operators who respond by searching for a missing firmware release will not find one, and the time spent searching is time not spent reducing exposure.

Why AI-generated scripts change the calculus

The advisory frames AI as an evolution in threat actor capability rather than an autonomous attacker. Target identification, confirmation of intent, and the issuance of physical process commands remain human decisions. What changes is the cost and speed of building a working tool.
Historically, developing a reliable PLC interaction tool required three overlapping skill sets: industrial protocol knowledge, exploit development, and familiarity with the specific process environment. That combination is scarce, and the resulting development timelines were measured in weeks. An actor who can supply device model, firmware version, and open port information to a language model and receive a working snap7-based Python script has compressed that timeline substantially and removed the need for one of the three skill sets.
The scripts' disguise as legitimate monitoring software compounds the problem. Signature-based detection depends on distinguishing malicious tooling from benign tooling. When the malicious tool speaks the same protocol, uses the same library, and issues the same read operations as an authorized monitoring application, behavioral baselines become more important than signatures.

What the reconnaissance pattern implies

The advisory describes the activity as reconnaissance and capability development rather than immediate disruption. That framing is consistent with an actor mapping an environment before deciding how to use it. Read and write access to ladder logic is not a subtle capability. An actor who can modify control logic can alter process behavior, and the advisory lists potential consequences including process disruption, safety incidents, equipment damage, data compromise, and cascading effects.
The advisory also notes that the targeting activity is broader than Siemens devices and that all PLC owners and operators should apply relevant mitigations. No specific CVE identifiers or indicators of compromise are listed, which means detection cannot rely on matching a published IOC list.

Exposure context

ZoomEye indexes 173 assets matching the app="Siemens S7" fingerprint and 10,160 matching app="Siemens SIMATIC". A broader query for port="102" returns 161,764 assets, and device="plc" returns 95,395.
These numbers require careful reading. The port 102 count describes services reachable on the S7comm-associated port, not confirmed Siemens controllers, and not confirmed vulnerable devices. The device="plc" count spans all vendors. The product-fingerprint counts describe indexed product assets, not confirmed exploitable instances. What the figures do establish is that the relevant protocol surface is large enough that exposure reduction is a meaningful control rather than a theoretical one.

Defensive implications

The advisory's mitigations follow from its framing. Because the root cause is exposure and configuration rather than a code defect, the effective responses are structural.
Network segmentation is the primary control. A PLC that cannot be reached from the internet cannot be scanned by an internet scanning service. Where remote access is operationally required, it should terminate at a controlled intermediary rather than at the controller.
Firmware currency remains relevant even without a single fixing patch, because the advisory refers to known vulnerabilities that are exploitable when devices are exposed or insufficiently segmented. Siemens ProductCERT provides firmware updates addressing known issues.
Authentication hygiene matters because default and weak credentials lower the effort required after exposure is established. Strong passwords and model-specific hardening guidance address this directly.
Monitoring for anomalous S7comm activity provides a detection path that does not depend on IOCs, which the advisory does not supply. Unusual read patterns, unexpected write operations to ladder logic, and connections from unfamiliar sources are the observable signals.

Limits of this analysis

Two limits deserve emphasis. First, the advisory lists no CVE identifiers and no IOCs, so any specific detection rule presented as derived from AA26-231A would be an extrapolation rather than a citation. Second, the ZoomEye counts above describe protocol and product exposure, not confirmed compromise or confirmed vulnerability. They indicate where to look, not what has happened.
The broader lesson is about how to read an advisory that is not a patch announcement. AA26-231A documents a change in attacker capability applied against a long-standing exposure problem. The response it calls for is configuration and architecture work, and that work does not have a release date.

References

NSA, CISA, FBI, DOE, EPA — Joint Cybersecurity Advisory AA26-231A, 2026-08-19
Siemens ProductCERT advisory SSB-104599
National Vulnerability Database — https://nvd.nist.gov/
ZoomEye, app="Siemens S7" — 173 assets; app="Siemens SIMATIC" — 10,160 assets; port="102" — 161,764 assets; device="plc" — 95,395 assets; collected 2026-09-16

How I Understand Modern AI as a Developer

OnaEiuspkz — Wed, 16 Sep 2026 07:05:56 +0000

Nowadays AI is everywhere in software development, yet many people misunderstand its real capability.

AI is not a magic solution that can solve every problem automatically. It works best as a powerful assistant. It helps write boilerplate code, explain complex concepts and speed up debugging work. However, human judgment is still essential. We need to verify outputs, fix logical flaws and fit generated results into actual business requirements.

For developers, the key is learning to collaborate with AI instead of fully relying on it. Mastering prompt skills and critical thinking will bring more value than blindly trusting generated answers.

AI extends our ability, but human experience still leads the final decision‑making.

My First Technical Note on DEV.to

OnaEiuspkz — Wed, 16 Sep 2026 07:04:58 +0000

Hello DEV community!

This is my first published article. As a software developer, I keep learning new technologies and building small side projects in my free time.

I will record real‑world development issues, practical tips and learning thoughts in future posts. I hope to get feedback and inspiration from fellow developers here.

Looking forward to communicating and growing together with you all. Thank you for reading.