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

This is an article about the internals of Win32k (Windows's GUI subsystem) and their callouts, with the purpose of shedding light on a very undocumented and crucial subsystem in Windows :)

I work at Glow, and our Glow Labs research team just published this.

Developers asked their coding agents to share screenshots of their work for code review. Some agents decided on their own to create a brand-new public repo, usually under the developer's personal account, and put the screenshots there.

The team found 13k+ images across 300+ organizations, including a frontier AI lab and a Fortune 500 travel company. They show billing records, a financial firm's treasury console, and features weeks or months from release.

Since these repos weren't in the companies' own GitHub orgs, security teams never saw them.

Affected orgs have been notified. The writeup covers why the agents did this and where to look: https://glow.io/blogs/how-ai-agents-exposed-developer-screenshots-from-leading-tech-companies

Proton Mail confirmed and paid for an email-spoofing bug, then left it unfixed for 16 months

Unlike traditional approaches, console named-pipe injection does not use VirtualAllocEx and WriteProcessMemory. Instead, it takes advantage of read and write operations through a named pipe, along with the way console programs store interactive commands in memory.

GET-only egress to full code execution: chaining a URL mirror and a screenshot service

A technical audit evaluating the security defaults of 15 official Helm charts used for AI serving, vector databases, and Model Context Protocol (MCP) agents (including KubeRay, vLLM, LiteLLM, Qdrant, Weaviate, and Flux159 MCP).

Key findings from static manifest analysis and live single-pod lateral movement probes on a test cluster:

• Plaintext Secret Handling: LiteLLM database migration Job embeds raw database passwords in container environment variables (F-13).
• Unauthenticated Remote Code Execution: KubeRay defaults accept unauthenticated job submissions via HTTP, running commands inside a container with passwordless sudo access.
• Over-privileged Agent Access: Flux159 Kubernetes MCP server mounts a ClusterRole with cluster-wide Secret read and pod exec permissions, exposed without an authentication token over HTTP.
• Static Scanners vs CRDs: Standard static analysis tools (Checkov, Trivy, Kubescape) failed to inspect pods nested inside Custom Resource Definitions like Ray clusters.

The paper documents reproducible test commands, network capture logs, and remediation Helm snippets. Scrubbed raw probe logs and results tables are available on GitHub: https://github.com/Sorami-Consulting-AU/ai-kubernetes-helm-chart-security

We scanned 7,040 randomly sampled U.S. local-business directory listings and graded the response headers against a published rubric. Of the 4,688 live sites, 49.7% met none of seven header criteria, and 8 sites (0.17%) passed a strict header-only script-CSP rule. Rubric, parser rules, code and de-identified data are all on the page.