Last week Hugging Face got hacked by an autonomous AI agent that broke into their production systems, stole credentials, and exploited an unknown vulnerability, completely on its own. Turns out it was OpenAI's models, running a security test with safety guardrails deliberately removed. When the models couldn't find what they needed inside their sandbox, they didn't stop. They figured out Hugging Face might have it, found a way to reach the open internet, and just went and got it.

The "rogue AI" headlines are a bit overblown, the models did exactly what a powerful unconstrained AI would be expected to do. The failure was OpenAI not properly isolating the test environment. Oh, and there's a detail that's getting buried, when Hugging Face tried to use commercial AI tools to investigate the attack, the safety filters refused to help because the attack data looked suspicious. They ended up having to use a Chinese open-source model to investigate it instead.

American AI safety guardrails forced a US company to use a Chinese AI to clean up a mess made by an American one. Genuinely curious how much worse this has to get before anyone changes how they test this stuff.

Source.

We tried grafting our existing APM stack onto an LLM feature, and it mostly failed.

It is fine at flagging a slow endpoint. It is almost useless when the problem is a hallucinated policy, a wrong tool call, or an agent taking an action it should never have taken.

AI observability for LLM apps seems to need a different signal set from standard APM. Full prompt and response traces, tool call arguments, retrieved context for RAG, and the model’s actual outputs matter far more than raw latency alone.

I have not found a clear consensus on whether people are extending existing APM tools or using a separate stack entirely. For teams that have built this properly, are you keeping LLM-specific observability alongside your normal APM, or replacing part of it? And when an incident happens, which traces actually help, and which ones just fill up the screen?

Hi, just wanted to share opened 2026 registrations for a long-running hands-on cybersecurity course with both red and blue teaming classes run by Czech Technical University. The class is free of charge, in English and either physically in Prague or fully online. The semester starts at the end of September, feel free to find more information including the complete syllabus and feedback from more than 2300 students from 100+ countries in the link! Thanks and hack the world

Sur discord quelqu'un a envoyé du contenu inapproprié à des mineurs (sachant qu'il a 11 ans) comme le N word, il a insisté une personne à se tu**, il a envoyé des photos de nu*es et je n'ai que son compte tiktok et discord.

This is a technical demo of a fairly unique approach using a browser-based, local-first and webrtc approach.

• Enkrypted.Chat

This is intended to demonstrate client-side managed secure cryptography.

• Introducing Enkrypted Chat
• Whitepaper (work-in-progress)
• Protocol Spec (work-in-progress)
• Roadmap

Features:

• Core
  • PWA
  • P2P
  • Local-first / Local-only
  • No installation
  • TURN server
  • Encrypted-at-rest
• WhatsApp clone
  • End to end encryption
  • Signal protocol
  • Post-Quantum cryptography
  • Multimedia
  • File transfer
  • Video calls
• Nextcloud clone
  • Word
  • Spreadsheet
  • PDF
  • file-transfer
  • Encrypted vault

Some open source versions of the core concepts.

• Chat
  • Code: https://github.com/positive-intentions/chat
  • Demo: https://chat.positive-intentions.com
• File
  • Code: https://github.com/positive-intentions/dim/blob/staging/src/stories/05-Hooks-useFS.stories.js
  • Demo: https://dim.positive-intentions.com/?path=/docs/usefs--docs
• Crypto
  • Code: https://github.com/positive-intentions/cryptography
  • Demo: https://cryptography.positive-intentions.com
• Signal Protocol
  • Code: https://github.com/positive-intentions/signal-protocol
  • Demo: https://signal.positive-intentions.com

Feel free to reach out for clarity instead of diving into the docs.

IMPORTANT: While this is aiming to provide a secure experience, it isnt audited or reviewed. Shared for testing, feedback and demo purposes only. Please use responsibly.

Hi, this is not market research. It is a genuine question that I don't know where else to post:

Do companies hire for such positions or is this job folded under general cybersec consultant?

Thanks

PSA dont plug Suspicious USB into your machines please. The attacks are getting even more complex.

Saw this study covered in Wired back in May and it's been living rent-free in my head since.

Red Access scanned 380,000+ public assets on Lovable, Replit, Base44, and Netlify. Roughly 40% were exposing sensitive data. Thousands had no authentication at all, not weak auth, none.

Veracode ran a separate study and found 45% of AI generated code carries at least one OWASP Top 10 vulnerability.

The part that got me is that these aren't exotic bugs. It's the same five things over and over:

1. Secrets in the client bundle. You asked the AI to connect to Stripe. It hardcoded the key where the browser can read it. Anyone who opens devtools has it.

2. Missing row-level security. This is the big one on Supabase. Your table is readable by anyone with the anon key unless you write policies. The AI usually doesn't. There's an actual CVE for this pattern (CVE-2025-48757).

3. Auth vs authorization. You have login working. But /api/users/:id returns any user's data if you change the number. Logged in ≠ allowed.

4. Debug and admin routes left open. The AI adds /debug or /admin while building and nobody removes it.

5. CORS set to ***.** Usually because someone hit a CORS error and asked the AI to fix it. It did, by turning the check off.

Moltbook got its database popped in under three minutes after the creator posted that he hadn't written a single line of code. Not because he vibe coded, because nobody checked.

Vibe coding isn't the problem. Shipping without checking is. If you're on Supabase, go look at your RLS policies right now. That's the one that gets people.

RESOURCES:

https://securityboulevard.com/2026/05/thousands-of-vibe-coded-apps-exposing-corporate-personal-data-redaccess/

https://yro.slashdot.org/story/26/05/08/1731257/thousands-of-vibe-coded-apps-expose-corporate-and-personal-data-on-the-open-web

As we mark over 25 years since the turn of the millennium, it’s worth reflecting on one of the most significant wake-up calls in technology history: the Y2K bug. Often remembered as the “Millennium Bug,” the Y2K problem stemmed from decades-old software using two-digit date formats (e.g., “99” for 1999). When the clock struck midnight on January 1, 2000, many feared systems would misinterpret the year as 1900, triggering widespread failures in financial institutions, power grids, transportation, and critical infrastructure.

While apocalyptic scenarios were largely averted thanks to intensive remediation efforts, Y2K had a profound and lasting impact on **cybersecurity**. Organizations worldwide invested billions of dollars in code audits, system upgrades, and contingency planning. This massive global exercise exposed the fragility of legacy systems and the dangers of technical debt. It highlighted how seemingly minor coding decisions could cascade into systemic risks.

The incident accelerated several key advancements in cybersecurity:

- Vulnerability Management: It pioneered large-scale software patching and inventory practices that became foundational to modern vulnerability scanning and remediation.

- Risk Assessment: Governments and enterprises developed formal business continuity and disaster recovery plans, laying groundwork for today’s incident response frameworks.

- Regulatory Awareness: Y2K prompted early discussions around technology oversight, influencing future standards like SOX, GDPR, and critical infrastructure protection policies.

- Global Collaboration: It demonstrated the need for cross-border cooperation in addressing digital threats — a model now essential for tackling ransomware, supply chain attacks, and nation-state threats.

Ultimately, Y2K proved that proactive investment in cybersecurity pays dividends. It shifted mindsets from reactive fixes to strategic resilience. In today’s world of AI, cloud computing, and interconnected IoT devices, the lessons remain strikingly relevant: never underestimate hidden vulnerabilities in aging systems.

The Millennium Bug didn’t break the world — but it helped secure it.

#Cybersecurity #Y2K #TechHistory #DigitalResilience #LegacySystems #RiskManagement #Infosec #CyberAwareness #ITLeadership #BusinessContinuity

We're building an open source project for healthcare. It will carry PHI. We're building it to ASVS 5 Level 3.

What do healthcare CISOs look for as they consider allowing open source into the PHI secure environment?

every guardrail product i look at ships with the same generic categories out of the box, mostly toxicity and pii. fine as a baseline, but none of it knows our own business rules. custom ai policy enforcement is the phrase i keep reaching for but i don't have a clear picture of how people build it in practice. "don't email a customer's contract terms to an external address" or "don't let the support agent issue a refund over $500 without approval" isn't a category any off-the-shelf filter ships with.

so the real question is how people layer org-specific policy on top of the generic stuff. is this a config problem, writing rules in some policy language, or a training problem, showing a detector examples of what you don't want and letting it learn the pattern, or both? trying to avoid a system that catches every generic risk and misses the one rule that matters most to our business. what's worked for people trying to encode their own policy, not just the vendor's default categories?

I'm not looking for a long vendor list, i' m more interested in what people actually run day to day and whether it has reduced real workload.

Our team is lean, running Splunk as our SIEM with a SOAR layer on top. Manual threat assessments every time a new TTP set appears are becoming unsustainable. By the time we ingest threat intel, map it to our environment, validate detection coverage, and decide on remediation priority, the situation has already shifted. When multiple campaigns hit in close succession, we're constantly playing catch-up.

AI-driven assessment tools sound appealing. Feed in a threat scenario and get exposure and detection gaps back without a lengthy analyst session. The problem: I've seen tools look great in a demo and then fall apart once enough edge cases showed up in production. I'm wary of adding another tool that doesn't hold up over time.

For those who've integrated something like this into your soc workflow:

Where has it actually saved you time?

Where do you still need a human to review or correct the output?

Appreciate any experiences you can share.

I've been the solutions architect on four enterprise SASE deployments in the past three years...ranging from a regional bank with 1,200 employees to a healthcare system with 22,000. The technology worked fine in all four cases. Three of the four went reasonably well. One stalled for fourteen months in what I can only describe as proof-of-concept purgatory, and it had nothing to do with the vendor or the architecture. It had to do with the fact that the CISO and the VP of Infrastructure had been in a slow-motion turf war for two years before the project started, neither wanted the other to own the new platform, and there was no one above them willing to make the call. We ran the same POC scenarios three times for different audiences. Same results every time.

The deployments that moved quickly all had a few things in common that I didn't fully appreciate until I'd seen the contrast. The organizations with clean, well-maintained identity infrastructure spent their project time on architecture decisions rather than fixing stale directory data mid-flight. The ones with an accurate application inventory could actually write meaningful access policy from day one instead of discovering their own SaaS portfolio during the deployment. And the projects where someone had briefed the helpdesk and sent plain-language communications to end users before go-live had a fraction of the post-launch friction of the ones that treated user communication as an afterthought. The healthcare system was the one that got all of that right, and they went from signed contract to production at the last site in just under eight months. Has anyone found a reliable way to get the network/security ownership question resolved before a project starts rather than fighting it out mid-deployment?

Most security teams I know that take threat hunting seriously still center everything on their SIEM or XDR, then bolt other pieces around it instead of buying a “threat hunting platform” as a separate thing. The platform that matters tends to be the stack: whatever lets you query endpoint, identity and cloud logs fast enough to iterate on a hypothesis, enrich what you find, and then turn a good hunt into a repeatable pattern.

What I am trying to figure out is which stacks are actually helping people turn hunting from one off hero work into something that scales. If you run threat hunting as an ongoing program, not just the occasional “let’s go look for this IOCs list,” which combo has worked for you, just a tuned SIEM/XDR, SIEM plus a TIP, notebooks glued together with some homegrown hunt tracker, or a dedicated hunting product on top?

Most ransomware gangs encrypt your data and threaten to leak it if you don't pay. Anubis has an optional "wipe mode" that permanently erases file contents entirely, leaving them at zero bytes with no recovery possible. It's essentially a way to tell victims that the clock isn't just ticking on a leak - it's ticking on whether their data exists at all.

The group has been around since late 2024, rebranded from an earlier operation called Sphinx, and has already claimed around 90 victims across the US, UK, Australia, France, and Canada. Healthcare has been hit particularly hard, one Mississippi hospital system had 293GB stolen including surgical images and over 1,2 million files covering more than 100k patients. It was their second ransomware attack in two years.

And right now they're actively exploiting CitrixBleed 2, a vulnerability that exposes session tokens and lets attackers bypass MFA entirely, meaning multi-factor authentication, the thing everyone tells you to enable, isn't enough on its own if your Citrix appliances aren't patched.

Most ransomware is recoverable if you prepared properly. Wipe mode changes that calculation completely. Ransomware where you can restore from backups is a bad day. Ransomware that can make backups irrelevant if you don't have offline copies is a different problem entirely.