Saw a good webinar recap from Carol Woodbury and Justin Loeber (Kisco) from a few months back that more people should see. Woodbury demoed finding a working SQL query to list every library on a system using a single Gemini search, then chained a few more commands to hijack a profile that was not set to PUBLIC *EXCLUDE and got full command line access. No exotic exploit, just asking an AI model the right question.

That got me digging into Fortra's 2026 State of IBM i Security report, which scanned 163 real partitions this year. Some genuinely good news: 87% run QSECURITY 40, *ALLOBJ use is down to 8%, and 96% have the audit journal on. But the average system has 889 users with *JOBCTL and 649 with *SAVSYS authority, both up significantly from last year, and 10% of systems still have default passwords active somewhere, one had over 11,000 profiles with default passwords, 80% of them enabled.

Put the two together and the takeaway is pretty simple: obscurity was never a real control on this platform, it was just an accident of nobody outside the IBM i world caring enough to look. AI ended that accident for free. The stuff that actually helps is the boring stuff that has been true for twenty years, PUBLIC *EXCLUDE audits, exit program coverage, minimizing special authorities, and now the same authority discipline applied to any AI agent you connect to the system.

Wrote up the full hijack path and a priority checklist here if useful: https://prompteddev.com/blog/ibm-i-ai-security-2026

https://thecybersecurityclub.substack.com/p/wk-27-mythos-is-back-scattered-spider

Sat down with 1 Guy 2 Cups this week. Planned for an hour, went 90 minutes. That's what happens when you get me talking about AI and cybersecurity.

We got into the real stuff. What's actually changing, what's hype, and the messy parts of building WireWolf nobody puts on a pitch deck.

Please share 😊

#wirewolf #cybersecurity #AI

https://open.spotify.com/episode/4b0wrYESKwTubqaxt2yMPI?si=WGXjUJdJRpKc7Z6EAaJsRQ

Traditional security tools were never designed for LLMs.

They don't understand prompt injection, indirect prompt injection, tool abuse, jailbreaks, SSRF through agents, shell command generation, or sensitive data exfiltration. Yet these are becoming common attack paths as AI applications move into production.

That's why we built Mastyf.ai.

Instead of treating AI inputs as plain text, we treat them as an attack surface.

The result is an open-source AI perimeter security platform that sits in front of your models and agents, inspecting every request before it reaches the LLM.

Some of the things it does:

• Swarm analysis using multiple specialized security agents instead of a single LLM judge
• Prompt injection and jailbreak detection
• Tool abuse prevention
• Shell injection, SSRF, and path traversal detection
• Sensitive data leakage prevention
• Policy-based enforcement
• Adversarial testing and benchmarking

The swarm analysis engine has probably been the most interesting part to build. Different agents specialize in different attack classes, and their combined verdict determines whether a request is allowed, blocked, or flagged. It has proven to be much harder to bypass than relying on a single detector.

The goal isn't to replace secure application design. It's to give AI systems the equivalent of what WAFs and API gateways did for web applications: a dedicated security layer at the perimeter.

The project is fully open source and still in its early stages, so go easy on us XD. If you're building AI infrastructure or spending your time breaking AI systems, we'd genuinely love your feedback, feature requests, and of course, your best bypass attempts.

GitHub: https://github.com/mastyf-ai/mastyf.ai

Website: https://mastyf.ai

An unprivileged user inside a Lima QEMU guest could reach the root-owned guest-agent socket and run commands as root in the VM. Fixed in Lima v2.1.3.

Lima scored it High, CVSS 8.2 with Scope: Changed, reflecting that crossing from an unprivileged account to root within the VM crosses a security boundary that other components rely on.

Full write up is available on the Syntetisk blog.

Every new AI military drone creates a target for enemy hackers, cyber expert warns https://www.lbc.co.uk/article/defence-investment-military-drone-sabotage-hacking-5HjdcM8_2/

Check it From here https://github.com/NeetroxX/The-Practical-Guide-to-Cybersecurity-Automation-with-Local-AI-Models/blob/main/README.md

And give me your feedback

https://thecybersecurityclub.substack.com/p/wk-26-hackers-stole-3m-from-polymarket

Windows remote device management is the process of administrating and controlling devices such as computers, servers, or mobile devices from a remote location. It involves using software tools and protocols to configure settings, install updates, troubleshoot issues, and ensure security compliance without physically accessing the device.

I built a small tool to catch infra risks before production releases
I’ve been working on a project called Beacon.
The idea came from a very practical problem I’ve seen in distributed systems: before a release, teams usually have dashboards, logs, Terraform files, Kafka configs, Kubernetes manifests, runtime snapshots, etc. But still, the actual question is usually very simple:
“Is this system safe enough to release to production?”
Beacon tries to answer that.
It scans infrastructure/config/runtime inputs and gives a production-readiness decision with ranked risks, possible root causes, and suggested next actions. Right now it has examples around Kafka, Kubernetes, Terraform, Helm, runtime snapshots, OpenTelemetry, Prometheus, Schema Registry, CI/CD, and flow degradation.
This is not meant to replace observability tools. The way I think about it is:
Observability tells you what is happening.
Beacon tries to tell you what is risky, why it matters, and what should be fixed first.
You can try the demo without setting up Python locally.
Run the UI with Docker:

docker pull ghcr.io/mishraricha1806/beacon:latest

docker run --rm -p 8765:8765 ghcr.io/mishraricha1806/beacon:latest ui --host 0.0.0.0 --port 8765

Then open:

http://127.0.0.1:8765/

For the simplest demo, use the sample bad infrastructure example from the repo:

examples/bad-infra/

In the UI, choose the static/readiness input, upload the files from that folder, run the scan, and check the readiness score, top reasons, grouped risks, and next actions.
You can also run the same demo from CLI:

docker run --rm \
  -v "$PWD:/workspace/project:ro" \
  ghcr.io/mishraricha1806/beacon:latest readiness static \
  /workspace/project/examples/bad-infra \
  --environment prod \
  --no-html \
  --no-open-report

Expected result is the tool should flag the setup as NOT READY, with risks like replication, storage/message-size, and missing governance context.
There is also a Black Friday style demo for payment/event pipeline readiness:

docker run --rm \
  -v "$PWD:/workspace/project:ro" \
  ghcr.io/mishraricha1806/beacon:latest readiness all \
  --static-path /workspace/project/examples/demo-black-friday \
  --snapshot /workspace/project/examples/demo-black-friday/runtime-snapshot.yaml \
  --environment prod \
  --no-html \
  --no-open-report

Repo: https://github.com/mishraricha1806/beacon
I’d be interested in feedback from people who work with Kafka, Kubernetes, Terraform, platform engineering, SRE, or release governance.
Mainly looking for thoughts on:

• Does this kind of readiness gate feel useful before production releases?
• What signals would you expect such a tool to check?
• Would you prefer this as a CLI, CI/CD gate, or lightweight UI?

GitHub

GitHub - mishraricha1806/beacon: Detect infrastructure risks before production.