In enterprise environments, identity effectively became the control plane once network perimeters broke down (e.g. zero trust, et cetera).

I’m seeing a similar pattern emerging on the public internet via age verification and safety regulation, but with identity moving closer to the access layer itself.

Not just: “Are you over 18?”

But: identity assertions are becoming part of how access is granted at the OS/device/app store level.

From a security perspective, this seems to introduce some new attack surfaces:

• high-value identity tokens at the OS/device level
• new trust boundaries between apps, OS, and third-party verifiers
• incentives to target device compromise or token reuse rather than account-level bypass
• potential centralisation of identity providers as enforcement points

Questions I’m trying to think through:

• Does this effectively make identity providers the new perimeter/control plane?
• How would you model this system (closer to DRM, identity federation, or something else?)
• What are the likely failure modes if this layer becomes centralised?
• Are decentralised / on-device credentials actually viable from a security standpoint, or do they just shift the attack surface?

Curious how people here would threat model this or where the obvious breakpoints are.

NTLM-Relaying has been proclaimed dead a number of times, signing requirements for SMB and LDAP make it nearly impossible to use captured NTLM authentications anymore. However, it is still possible to relay to many webservers that do not enforce Extended Protection for Authentication (not just ADCS / ESC8).

A missing authentication check in TP-Link’s Archer NX series allows unprivileged attackers to upload firmware. The update lands as the company defends a Texas lawsuit alleging deceptive security claims.

Analysis of the LiteLLM incident: stolen CI tokens → malicious PyPI releases → credential exfiltration from runtime environments.

With focus on trust boundaries in CI/CD and secret exposure.

We pentested a web app built 100% with AI — no human-written code. Functional, clean, well-structured. But security-wise, we found critical issues on day one: LFI, IDOR, vulnerable dependencies, and more.

AI-generated code is not secure by default. And vibe coding moves fast enough that security gets skipped entirely.

Full writeup with technical details and recommendations: https://www.hackmosphere.fr/en/?p=3803

Anyone else seeing this pattern in AI-generated apps?

Breach occurred at Navia Benefit Solutions, a 3rd party, not HackerOne infra.

Around 287 HackerOne employees PII leaked.

Navia delayed breach notifications by weeks. Filed at Maine AG.

Navia was independently breached. Over 10K US employee's PII exposed.

Reports point to an auth flaw (BOLA-type) enabling access to employee PII (SSNs, DoB, addresses, benefits data).

Exposure window: Dec 2025 to Jan 2026.

Root cause: EspoCRM's formula engine operates outside the field-level restriction layer — fields marked readOnly (like Attachment.sourceId) are writable through it. sourceId is concatenated directly into a file path in getFilePath() with no sanitization. Chain: modify sourceId via formula → upload webshell via chunked upload → poison .htaccess → RCE as www-data. Six requests, admin credentials required. Coordinated disclosure — patched in 9.3.4.

I’ve written a long-form analysis on how age-verification laws are pushing identity into internet infrastructure (OS layers, app stores, identity credentials), rather than staying at the application/content layer.

It looks at how enforcement is moving “down the stack”, with governments increasingly targeting platform chokepoints like Apple/Google and device-level controls.

The piece draws on UK identity history, US telecoms, and current global regulation.

Curious how people here think this holds up technically, especially around enforcement, bypass (VPNs, forks, sideloading), and where this creates new attack surfaces.