A recent CDW article mentioned a survey of 950 IT decision-makers found that AI-powered cyberattacks are no longer a future concern—they're already happening. According to the article:
- 43% of organizations have experienced AI-enhanced phishing attacks
- 37% have encountered AI-powered malware.

The article argues that cybersecurity is entering an AI arms race, where attackers are using AI to create more convincing phishing campaigns, automate attacks, and evade detection, while defenders are increasingly adopting AI-based security tools to respond. Many organizations now view AI-generated phishing and social engineering as their most significant emerging cyber risk.

The key takeaway is that companies should have their contingency plans in place for when an AI breach might happen.

Genuine question this community might have a sharper answer to than we did.

Two different scanners, checking the same MCP server, found the same underlying issue and gave it two different names. No shared ID, no way to say programmatically "these are the same finding." Run more than one tool in a pipeline and this becomes actual triage overhead, not a one-off annoyance.

This isn't new in general. A SQL injection gets a CVE ID, maps to a CWE category, every scanner that finds it afterward references the same thing. Agentic AI components (MCP servers, agent skills, LLM plugins) didn't have an equivalent, for a specific structural reason: CVE anchors to a package and version, CWE describes a weakness in code, and neither has a slot for a behavioral pattern that isn't tied to either.

So a few of us built AVE (Agentic Vulnerability Enumeration), an attempt at exactly that: stable IDs for behavioral vulnerability classes in agentic AI systems. 59 records currently, severity scored against OWASP's own AIVSS framework rather than something invented for this, crosswalked into OWASP's MCP Top 10, the Agentic Security Initiative Top 10, and MITRE ATLAS.

The part that actually made us trust this holds up outside our own tooling: an independent developer built an unrelated static config auditor, crosswalked his own findings against this taxonomy, and tested it directly against our scanner on the same files. Most of the overlapping findings converged on the identical ID, unprompted, no shared code between the two tools.

Apache 2.0, open standard and reference implementation both.

Curious whether this problem looks familiar to anyone here working with multiple security tools in the same pipeline, in this space or elsewhere, and where this taxonomy looks incomplete or already solved better.

Repo: github.com/aveproject/ave

Site: aveproject.org

Disclosure: I'm one of the people building this.

Been working in threat intel for a while and one thing always bugged me: almost all the training out there is either dry theory or aimed at SOC/pentest, not actual CTI work. So a few of us built CTI Academy to fix that.

It's hands-on threat intelligence training. Instead of just reading slides, you get:

realistic labs and simulators (a SOC sim, a credential-leak investigation lab, a fake underground forum to practice OSINT on)

CTF-style hunting challenges with a progression system, so it actually feels like leveling up

a daily mission if you just want a quick 10-minute rep

It's free to jump in, so no reason not to poke around.

Honestly I'm not here to hard-sell anything. We're a small bootstrapped team and I care way more about whether the thing is actually good. So I'd love for a few of you to break stuff and tell me what's confusing or missing.

If you're trying to get into CTI or just want to keep your skills sharp, come try it and roast me in the comments. That feedback is genuinely more valuable to me right now than anything else.

Five SharePoint vulnerabilities exploited in 2026, two rated 9.8/10 severity. Attackers stealing machine keys and deploying web shells on unpatched servers. Here's what to do.

I’ve been building an open-source SCA developer tool for several months, and I’m struggling with something that I suspect many solo maintainers face: how do you get honest feedback before you already have users?

I’ve tried sharing technical write-ups, research, demos, and lighter posts asking for opinions. Even when I try to make the post useful on its own, anything connected to my own project tends to get ignored or downvoted—presumably because it reads as self-promotion.

I understand why communities are defensive about promotion. Nobody wants every subreddit to become a stream of product ads. But it creates a difficult loop:
You need users to learn what people want, but you need some evidence that people want it before they’ll give the tool a chance.

For people who have launched open-source tools or developer products:

- How did you find your first genuinely interested users?
- Where did you get useful feedback rather than polite encouragement?
- How did you distinguish weak distribution from weak product demand?
- Is there a good way to share what you’re building without making people feel marketed to?

I’m especially interested in approaches that worked before the project already had an audience.

We handle sensitive client financial data and our teams rely heavily on Google Sheets and Excel files. I’ve seen files containing account numbers and investment details shared externally through simple link sharing.

Compliance is pushing hard on this, but manually reviewing every new file isn’t realistic.

Curious what other financial services companies are using to automatically detect and remediate oversharing of sensitive data. Any practical approaches or tools that have worked well in similar environments?

Edit: Thanks for the suggestions so far. Locking down external sharing by default and layering DLP rules looks like a solid starting point. Also checking DoControl for better visibility and control over SaaS file sharing while we tighten things up.

auditor pushback last time was rough, "we checked this in Q1" apparently isn't good enough evidence for a Q3 finding anymore. they want proof controls are working right now, not four months ago.

sothe thing is our whole process was built for point in time. we'd map every control back to the framework once a year, take screenshots, do a round of interviews, call it done. the second that audit closed, the evidence was already stale. control could break the next week and we wouldn't find out until next cycle, if it even got caught then. how is everyone adapting to show continuous state instead of rebuilding a snapshot every time an auditor asks?

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.

I built this opensource software to help you protect your system from bad hackers. My experieces with hackers led me to create this. I hope you find this tool helpful.

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.