❌

Reading view

[arXiv] Enhancing REST API Fuzzing with Access Policy Violation Checks and Injection Attacks

Fuzzing is a common technique to detect faults.

In the case of REST APIs, common types of faults are HTTP 500 server error responses, and mismatches with what declared in the OpenAPI specifications.

However, there are several types of security properties that can be automatically checked as well, even when there is no formal specification of the access policy of the API. For example, what if a PUT/PATCH is denied (403), but then a DELETE is accepted (2xx)?

The linked article on arXiv shows a series of experiments on more than 50 APIs using 9 different kinds of security "oracle" checks. Those are implemented in the open-source fuzzer EvoMaster.

submitted by /u/arcuri82
[link] [comments]
  •  

Attempting to evade an AI SOC with offensive agents

We have been toying with evading EDRs at Vulnetic with moderate success, so this time we wanted to put it against an in-house AI SOC. The idea is that the defense gets streamed logs on the network and can make decisions like quarantining or blocking potential attackers while also sifting through logs being streamed. This was with the last gen Anthropic models, so we will be redoing these tests with the newest gen from OpenAI and Anthropic shortly as in initial testing they seem to be 15-20% better already.

I think defense is lagging behind offense and there will be a come to Jesus moment where open weight models in a decent harness can evade modern SIEMs / detection mechanisms and when that happens there will be a problem. With regards to AI, it comes down to proper access control and so the fundamentals of networking and defense in depth will be vital in the future to fight against these AI threats. Happy to answer any questions and always looking for cool experiments to try!

submitted by /u/Pitiful_Table_1870
[link] [comments]
  •  

What Really Happened In There? A Tamper-Evident Audit Trail for AI Agents

Full disclosure: I work on community at Always Further, the team behind this. Not the author. Posting because Luke's approach to tackling this challenge is unique and of an interest to the netsec community.

The core idea: if an AI agent is compromised, any log the agent itself writes becomes part of the attack surface. The post walks through how they split auditing into a supervisor process the sandboxed child can't reach, then uses the same Merkle tree + hash-chain construction RFC 6962 (Certificate Transparency) uses to make edits, truncation, and reordering all detectable.

There's a concrete threat-model table near the end that lists what each attack looks like and what structurally stops it. Worth skipping to if you don't want the crypto primer.

submitted by /u/Remote_Parsnip_5827
[link] [comments]
  •  

Bitwarden CLI Compromised in Ongoing Checkmarx Supply Chain ...

Bitwarden CLI npm package got compromised today, looks like part of the ongoing Checkmarx supply chain attack

If you’re using @bitwarden/cli version 2026.4.0, you might want to check your setup

From what researchers found:

- malicious file added (bw1.js)

- steals creds from GitHub, npm, AWS, Azure, GCP, SSH, env vars

- can read GitHub Actions runner memory

- exfiltrates data and even tries to spread via npm + workflows

- adds persistence through bash/zsh profiles

Some weird indicators:

- calls to audit.checkmarx.cx

- temp file like /tmp/tmp.987654321.lock

- random public repos with dune-style names (atreides, fremen etc.)

- commits with β€œLongLiveTheResistanceAgainstMachines”

Important part, this is only the npm CLI package right now, not the extensions or main apps

If you used it recently:

probably safest to rotate your tokens and check your CI logs and repos

Source is Socket research (posted a few hours ago)

Curious if anyone here actually got hit or noticed anything weird

submitted by /u/ApprehensiveEssay222
[link] [comments]
  •  

OAuth 2.0 BCP Β§4.14 reuse detection in practice β€” race vs theft disambiguation

Standard advice for refresh tokens: rotate on every use, store hashed, set a short expiry. Done, right?

Not quite.

Rotation alone does nothing against token theft. If malware or XSS lifts a refresh token from a legit client, the attacker and the client race to rotate it next. Whoever loses the race gets a "token revoked" error β€” and the winner keeps the session.

From the server’s point of view, it just sees two valid requests seconds apart. No alarm, no signal, nothing.

The missing piece is what OAuth 2.0 Security BCP Β§4.14 calls refresh token reuse detection: if a token that was already rotated is presented again, treat it as evidence of compromise and invalidate the entire session.

The core idea

Every token belongs to a family (FamilyId), shared across all rotations of a single login.

If a rotated token shows up again (outside a small grace window), you revoke the entire family:

  • the attacker is locked out
  • the legit user is forced to re-authenticate
  • the session is no longer silently compromised

​

if (stored.ReplacedByTokenHash is not null && stored.RevokedAtUtc.HasValue) { var withinGrace = stored.RevokedAtUtc.Value.AddSeconds(graceSeconds) > DateTime.UtcNow; if (withinGrace) return Fail("token_recently_rotated"); // benign race (SPA tabs, retries) await RevokeFamilyAsync(stored.FamilyId, ip, reason: "reuse_detected"); return Fail("token_reuse_detected"); } 

Client-side it’s just one extra branch:

if (error.code === "token_reuse_detected") { // "You've been signed out for security reasons. Please log in again." router.push("/login?reason=compromised"); } 

You can also hook into it for observability (alerts, SIEM, etc.):

services.AddSingleton<IAuthEventSink, SlackAlertSink>(); 

The tricky parts

  • Race vs theft look identical. Two requests with the same token arrive. One is legit, one might not be. Only timing differs. Grace window too small β†’ false positives on flaky networks. Too large β†’ real attack window. ~30 seconds worked well in practice.
  • Revoking the whole chain. On reuse you must invalidate all still-active tokens from that session. A simple FamilyId + index makes this a single bulk update.
  • Concurrency is common. Multi-tab SPAs, retries, mobile reconnects β€” without a grace window, I was logging myself out constantly during tests.

I ended up adding this to a small self-hosted auth library I’ve been working on (https://www.reddit.com/r/dotnet/comments/1shpady/selfhosted\_auth\_lib\_for\_net/)

submitted by /u/No_Ask_468
[link] [comments]
  •  

Two new critical Spinnaker vulns allow RCE and production access

CVE-2026-32604 and CVE-2026-32613 are both 10.0 severity vulnerabilities in Spinnaker, which allow attackers to execute arbitrary code and access production cloud environments and source control.

They provide an easy path from a compromised workstation to more sensitive areas.

Our blog post contains a comprehensive technical breakdown and working POCs.

submitted by /u/Prior-Penalty
[link] [comments]
  •  
❌