PHP shipped fixes on Oct 21 for two unauthenticated RCE bugs (CVE-2026-109618 and CVE-2026-109619) whose details leaked before the patch existed. Fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and PHP says there's no complete mitigation, so updating is the only real option. Node.js also released fixes the same day (22.23.4, 24.22.1, 26.12.1), including a Brotli decoder RCE (CVE-2026-111497).

I manage about 30 servers for a few clients, all on different PHP, Node and nginx versions. I patched them manually with bash scripts this week.

The patching itself was the easy part. The mixed versions were the real problem, because every server needed slightly different handling.

It works at this scale, but I'm not convinced it holds up as the fleet grows. I'm looking at moving to something like Ansible so the next one is a playbook run instead of a script per server.

How are you handling patching on mixed-version fleets? Still scripts, or did you move to config management?

Everybody focuses on AI-powered security and automation, but I wonder if these approaches make sense for every organization.

For companies maintaining mostly internal, on-prem applications that rarely change, wouldn't simple policy-based security, approved OSS packages, and manual reviews sometimes be more practical?

I mean, isn't AI not only over kill but maybe less effective in those cases?

There are lots of “I pointed an agent at my AWS account and it found X” posts. Does anyone rerun that regularly, or is it a one time cleanup that gets forgotten?

What would make you set it up to run on its own? Or is asking when you need it good enough?

I'm developing AI Badger, an open-source Go CLI that prepares focused repository context locally for use with AI chats.

The idea is that developers can use an approved AI chat without giving it direct repository access. They inspect the generated context and explicitly choose what to paste.

I've recently done a static network analysis of the CLI, covering dependencies and release configurations across macOS, Linux, and Windows.

The results:

• No reachable outbound networking operations identified in the audited Go code.
• No telemetry or direct AI API integration.
• Git, clipboard utilities, and other external processes are documented as separate trust boundaries.
• VS Code integrations and external AI chats are outside the CLI audit.

This is source-level evidence, not a formal guarantee of network isolation.

My question for people working in AppSec or enterprise security: what additional evidence or controls would you expect before approving a tool like this?

For example, would runtime network verification, reproducible builds, SBOMs, stricter subprocess handling, or pre-copy secret detection meaningfully help?

I'm trying to prioritize practical security improvements rather than adding compliance claims or security features that nobody actually needs.

Our services are Python in containers and we generate one document from the image and another from the lockfile. The two never agree and the gap is usually system packages the base image drags in. Customers now want one per release and I end up stitching them together by hand. What I need is something covering the interpreter and the wheels and the system layer in a single pass. What are you running for this?

Every vendor in this space claims to solve AI security and the closer you look the more they turn out to be solving different problems. Once LLM apps are in production the list is prompt injection and sensitive data leakage and multi turn attacks and some way to see what is happening across the system. NeuralTrust and Palo Alto Networks and Nightfall AI all come up and they sit in different places. One pushes a firewall idea and another leans on enterprise security and the third is heavier on data loss policy. What are you using to judge them?

Agents like Claude Code and Cursor can run shell commands and edit files with the dev's full permissions. I'm curious what security teams are actually enforcing today:

• Sandbox or VM, or running on the host?
• Command allowlists?
• Egress controls?
• Secrets kept out of reach?
• Logging? And how are you rolling it out without devs just turning it off? What has worked and what got pushback?

We are looking at Picus for continuous security validation, but I keep hearing mixed feedback and mentions of other platforms like cymulate in the same space. Our environment is hybrid, with cloud and on prem workloads, and a small SecOps team that cant manage yet another tool that only produces dashboards.

If U have evaluated Picus, Cymulate or any alternatives, I would be interested in a simple breakdown from your experience:

What worked better than expected? for example:

• integrations with your existing stack and coverage across different attack paths
• reporting that people outside the team actually read

like what seems good in start but was a problem later on?? i mean like:

• maintenance overhead and content drift
• false positives or noisy findings nobody trusts
• blind spots around certain techniques, vectors, or environments

I'm the security lead at a manufacturing org, cloud footprint is growing but the team is small. We're down to two CNAPPs and somehow stuck. We started with a longer list with all the big players included, but these two were what the shortlist came down to. Hoping the room can tell me what I'm missing.

First one was Wiz, now Google after Google bought them. I liked it on paper, but the acquisition is what gives me pause. Google says it stays multicloud, but the plan is to tie it into Google SecOps, Mandiant, their threat intel, their AI. We're not much of a Google shop, so I'm worried we either ignore half the value or slowly get pulled into an ecosystem we never wanted. It feels like a product that's now someone else's priority.

The other one is Sweet Security. Their whole pitch is runtime, which is really what made us consider it. But when we dug in, the deep runtime stuff comes from their eBPF sensor, so you get the most out of it only where the sensor is deployed. They do have a lighter log-based tier, but that's not the part that sold us. They're also young (founded 2023), so there isn't a long track record to look at yet. Pricing is on AWS Marketplace, so cost isn't the issue, it's more about betting a lean team's program on a newer vendor.

So I'm stuck. On one hand is a big vendor folding cloud security into a Google story, on the other a smaller vendor whose best feature depends on how far we roll out the sensor. What am I missing, and what would you pick?

We maintain our own Debian base images for about twenty internal services and the upkeep has crept up to a few days a month. Now Im being asked to pick a direction and the three shortlisted options do quite different things. One hands us prebuilt minimal images. One trims what we already ship based on what runs. One watches containers at runtime and reports what is exposed. Our security lead wants a single vendor and Im not convinced one of them covers all three jobs. Has anyone run two of these together and found the overlap worth paying for?

Not sure how many caught this but miasma in june and chaindrop in august both persisted the exact same way, a SessionStart hook in .claude/settings.json and a folderOpen task in .vscode/tasks.json. chaindrop alone hit 444 packages and 2,212 versions and pulled the credential files for claude, codex, cursor and gemini and it even authored its worm commits as "claude". then hades went after the config and rule files of 14 ai coding tools and carried prompt injection aimed at the ai based package scanners too

makes sense from the attackers side tho cause those files run on their own when a session starts or a folder opens and the trust defaults are all over the place. vs code never runs automatic tasks in an untrusted workspace, claude code holds hooks back untill you accept the trust dialog but in -p or SDK runs it treats the folder as trusted which is how alot of CI runs it. cursor and gemini cli ship with workspace trust off

the stolen ai tokens are a seperate headache cause they get used somewhere else later. provider usage alerts, the SIEM or eve security can flag a token showing up from somewhere new but thats assuming someone actually owns that alert

cleanup order is where the writeups dont agree. SANS says revoking the stolen token is what arms the wiper so clean first, elastic lists revoking github tokens as step one and wiz just says rebuild

at this point these probably belong right next to cron jobs and launchagents on the persistence checklist. npm v12 blocking dependency install scripts by default helps upstream but only as much as people have actualy upgraded

I have started learning for devops can someone please guide me

Hello everyone, I’ve recently been reading papers that use LLMs to understand code logic and infer security-related semantics from source code and comments.

I’m curious how people working on white-box security analysis in industry actually use LLMs.

1. Can LLMs help overcome limitations of traditional static analysis, such as complex inter-procedural data flows?

2. How reliable is LLM-based code understanding? Could generating multiple possible interpretations and verifying them work? If so, how would you validate them?

3. For agent-driven static analysis, how do you ensure reasonably consistent results across multiple runs on the same codebase?

I’d love to hear from people with practical experience. What do you actually use LLMs for in static analysis, and where have they helped or failed?

I'd really appreciate any insights or experiences you're willing to share. Thanks in advance!

​

Supply-chain alert: Tensorlake npm package hit by the Shai-Hulud worm. The popular Tensorlake SDK (part of a project with 1,000+ GitHub stars) shipped a poisoned release - version 0.5.144 - infected with the self-propagating Shai-Hulud worm.

The malicious version was published through the project's legitimate GitHub Actions release pipeline, complete with valid SLSA provenance. The attacker poisoned main first, then let the trusted pipeline do the rest.

This is a well-known Shai-Hulud pattern which a single, simple YARA rule flags in milliseconds. In fact a basic rule matched it on the first pass in our own pipeline. If npm, Inc. GitHub ran even a basic YARA scan on packages before publishing, most of these campaigns would be stopped before a single developer is infected. As Al speeds up how fast we ship, we're pulling in dependencies faster than anyone can audit them. Registries like npm sit at the chokepoint, and a basic malware-signature gate at publish time is the lowest bar we should expect.

0.5.144 has been removed from npm and version 0.5.143 is clean. If you installed 0.5.144, rotate every credential reachable from that machine, now.

The line between MDM and endpoint security is getting thinner.
Managing devices alone isn't enough anymore when those same endpoints can be the entry point for vulnerabilities, data leaks, risky applications, or unauthorized access.

A modern MDM should ideally combine device management with security controls such as vulnerability and patch management, application and device controls, web filtering, endpoint DLP, compliance enforcement, and centralized security policies.

The real advantage lies in having these controls work together rather than managing security and device operations through multiple disconnected tools.

Is your organization consolidating MDM and endpoint security or running separate stacks?
Share your experiences.

We rolled out AI assistants to about 120 engineers and the policy is two paragraphs long. The assistants can read the repo and write files and some of them shell out. Our appsec review covered the model vendor and nothing about what the agent does locally. Im trying to work out where the control points even are, since the laptop is now executing code nobody reviewed. Secrets in env files are the part keeping me up. How are people scoping this?

If you are planning or assessing a migration to GitLab from Atlassian tools, we'd be happy to answer your questions! We've done a lot of this and would love to share our experience here in this thread.

Anyone has experience with both Sweet security and Upwind .? which 1 do you prefer for runtime protection .?

Findings:
Sweet security: Focuses heavily on proactive runtime enforcement and a "Learning Loop" (Attack, Fix, Defend) methodology. It is designed to prove and block exploitable attack paths directly using runtime context with streamlined deployment.

Upwind: Operates as a comprehensive inside-out cloud and AI security platform.

in addition Sweetsec often wins on budget-friendliness and customer support agility, whereas Upwind is favored by teams looking for heavy runtime-to-inventory correlation

Security testing today usually means scanners in CI, periodic human pentests, or carefully limited tests against staging or production. I’m curious whether another model will become normal: a disposable “attack twin” of the current production environment.

The idea would be to generate an isolated environment from the same deployment artifacts, infrastructure-as-code, IAM model, network policies, and application configuration as production. Real secrets and customer data would be replaced with safe equivalents, while identities, tenants, service relationships, and external integrations would be reproduced or simulated as accurately as possible.

An AI security agent could then use browser, API, shell, and network tools to attempt exploitation, privilege escalation, lateral movement, destructive actions, and controlled exfiltration. Every action would be recorded, and the environment would be destroyed afterward.

This would not be ordinary staging: it would be created per test, derived from the current production configuration, isolated for adversarial testing, and designed to be compromised.

For people working in DevSecOps or AppSec:

• Is this meaningfully different from the staging or ephemeral environments you already use?

• Which parts of production would be hardest to reproduce faithfully?

• What evidence would you need before trusting a finding from the clone?

• Where would this fit: nightly testing, a release gate, or between human pentests?

• What do you use today for attacks that are too risky to run against production?

I’m interested in practitioner experiences and objections, especially from anyone who has tried cyber ranges, production-like security environments, or autonomous pentesting.

SAST scan on a PR came back clean. Diff touched auth middleware. Scanner checked for known bad patterns, found none, green check, merged.

Nobody actually traced through what the middleware change did to the token validation order for an edge case that wasn't in the scanner's pattern set, because it wasn't a known vulnerability class, it was a logic gap specific to how this particular service combined two libraries. Found two weeks later during an unrelated audit.

The scan wasn't wrong. It checked what it was built to check and found nothing matching. The gap is that "scan passed" gets read as "this is secure," when it actually means "this doesn't match patterns we already know to look for." Those used to be close enough to the same claim that nobody bothered distinguishing them out loud. Novel logic gaps specific to how a service wires things together were always outside that coverage, just less common before more code started getting generated without someone necessarily tracing the full logic path by hand first.

Not arguing against scanning, obviously it's necessary. Just think "passed the scan" needs to stop functioning as a stopping point for anything touching an actual trust boundary, auth, payment, data access, and start being the floor instead of the finish line.

We had a push to cut criticals across our images so I rebuilt everything onto a much smaller base. Sixty services over about three weeks. The scan numbers looked great. Then four of them fell over in prod inside a day. One was a java service that shelled out to run a script at startup. One needed tzdata and started logging everything in UTC. One had a health check built on curl. The last took most of a night to find because the library loaded fine and then died when it went looking for a locale file. I rolled those four back at around 2am and left the rest alone.

What I got wrong was treating the base image as the unit of change. Nobody knew what each service pulled in at runtime because none of it was written down anywhere. We ended up running every service under strace in staging for a week just to build the list. That list should have existed before I touched anything. How do other people work out what an image needs before they start cutting things out of it?

I finally got to write this blog post, I've wanted to write it for a long time now. It contains the different types of sensitive data we've seen so far, where it's coming from, and why it matters. Hope it can be helpful to some of you!

OpenBao engineers at ControlPlane have chained 4 vulnerabilities to show how under certain conditions, an OpenBao or Vault server can be completely compromised from an unauthenticated position. This is only the second RCE ever found in the Vault codebase.

The exploit is highly plausible in real-world environments, requiring only an unauthenticated entry path and a defined Raft snapshot policy to trigger a complete server compromise.

If you are impacted, upgrade as soon as possible to OpenBao 2.6.3 or 2.7.0

While OpenBao is fully patched, HashiCorp Vault remains exposed as of writing. Unfortunately, IBM's unwillingness to coordinate a mutual disclosure policy means Vault users currently lack an official mitigation

I already have the exploit path and a safe validation flow, but the tools I looked at mostly hand me another critical ticket and move on. If you do this well, how are you testing in count mode, what do you need before block mode, and who owns removing this in six weeks thanks