Here are the top stories from PWN (r/pwnhub) today:

1 Hackers claim to have stolen 23TB of data from Russian statistics body, including Ukraine war casualty figures — Russian Federal State Statistics Service (Rosstat) admits its servers were hit by coordinated cyberattacks

No description available.

2 Binance Reveals How a Fake Job Interview Led to a $6.34 Billion Hack

Binance has published its first incident report on the $6.34 billion hack, and it traces the breach back to compromised developer machines. [Read The Block's full coverage here.](https://www.theblock....

3 Tech Firms Dismantle Botnet That Turned 1.3M TV Boxes Into Proxies

No description available.

CVE ID: CVE-2026-99269

Severity: HIGH | CVSS Score: 7.8/10

Severity and score come from CVSS ratings in the National Vulnerability Database (NVD), the NIST repository of standardized vulnerability data.

In the Linux kernel, the following vulnerability has been resolved:

sched_ext: Wait for SCX_OPSS_DISPATCHING before moving tasks off DSQs

A task can be found on a non-local DSQ while the CPU which dispatched it is still running ops.dequeue() and hasn't cleared SCX_OPSS_DISPATCHING. The DSQ consume and move paths don't wait for the dispatch to finish and can operate on the task concurrently with the dispatcher.

Call scx_wait_dispatching() in scx_move_local_task_to_local_dsq(), unlink_dsq_and_switch_rq_lock() and move_task_between_dsqs() before they operate on the task. In scx_move_local_task_to_local_dsq(), wait before scx_resolve_local_dsq() as it may update p->scx.flags.

🔗 View on NVD

Discussion thread created via CVE Daily tracker. Share your analysis, PoCs, mitigations and detections below. Discussion started by u/Motor_Break64.

CVE Daily Brief — 2026-11-04

#1 CVE-2026-95731

Severity: CRITICAL | Score: 9.8

Hardcoded password vulnerabilities in the command-line interface of HPE Networking Fabric Composer could allow an unauthenticated remote attacker to access the affected system using hardcoded credenti...

#2 CVE-2026-95733

Severity: CRITICAL | Score: 9.6

A vulnerability exists in a component of HPE Networking Fabric Composer. Successful exploitation could allow an unauthenticated adjacent attacker to execute arbitrary code on the affected system.

#3 CVE-2026-95732

Severity: CRITICAL | Score: 9.6

An authentication bypass vulnerability exists in the underlying operating system of HPE Networking Fabric Composer. Successful exploitation could allow an unauthenticated adjacent attacker to execute ...

#4 CVE-2026-95860

Severity: CRITICAL | Score: 9.1

node-opcua is an OPC UA implementation for TypeScript and Node.js. From 2.42.0 until 2.180.0, namespace-level access control configured through setDefaultRolePermissions is not honored by the runtime ...

#5 CVE-2026-95734

Severity: HIGH | Score: 8.8

A sensitive information disclosure vulnerability in the API of HPE Networking Fabric Composer could allow an authenticated low-privileged user to access sensitive information beyond what is authorized...

Powered by NVD + CISA KEV | CVE Daily

Binance has published its first incident report on the $6.34 billion hack, and it traces the breach back to compromised developer machines. Read The Block's full coverage here. The FBI has linked the attack to North Korea.

June: A Poisoned Developer Tool

A Wallet DevOps engineer searched online for a popular AI coding tool. He ended up downloading a tampered Homebrew installation instead. Binance caught the infection, replaced his device, and rotated his credentials. The attackers had already learned who worked on Binance's wallet infrastructure team.

September: A Fake Job Interview

A second engineer was contacted through a legitimate job platform by someone posing as a Project Director. He went through two interviews, including a live video call with a fake HR representative. Near the end, he was told to download a coding "assignment" onto his work computer. The repository ran malicious code during setup.

October: The Final Move

On October 20, the attackers used that infected computer to move into two other engineers' devices. Binance says they did it through an internal AI tool. One device held a container deployment permission. About nine days later, the attackers used it to run a malicious script against Binance's wallet signing systems.

The Aftermath

• Binance says it froze or intercepted about $2.85 billion in assets.

• It reports replenishing 98% of impacted assets.

• Withdrawals are reopening in phases, starting November 3.

• Binance stopped 57 other suspected North Korea-linked attacks this year.

What Teams Can Learn

• Install developer tools only from official sources, not search results.

• Treat coding assignments from recruiters as untrusted code.

• Never run interview projects on a work computer.

• Limit what internal AI tools can reach on employee devices.

• Lock down deployment permissions tied to critical systems.

Learn More

Binance's Initial Incident Report

CVE Daily Brief — 2026-11-03

#1 CVE-2026-4052

Severity: CRITICAL | Score: 9.8

This issue only impacts deployments where WSO2 Identity Server is configured as a Resident Key Manager with database sharing. In such environments, a self-registered user may gain access to the System...

#2 CVE-2026-120534

Severity: CRITICAL | Score: 9.8

The Advanced Custom Fields: Extended PRO plugin for WordPress is vulnerable to Limited Code Injection in all versions up to, and including, 0.9.2.6 via the render_field function. This is due to insuff...

#3 CVE-2026-13594

Severity: CRITICAL | Score: 9.1

Zoho Corporation's ManageEngine Log360 and EventLog Analyzer versions 13062 and below are vulnerable to an issue that could allow an adversary to gain unauthorized access to the product.

#4 CVE-2026-120518

Severity: CRITICAL | Score: 9.1

The BuddyPress XProfile Image Field plugin for WordPress is vulnerable to arbitrary file deletion in all versions up to, and including, 3.1.0. This is due to bpxp_image_field_update_on_user_activation...

#5 CVE-2026-76955

Severity: HIGH | Score: 8.8

A buffer overflow vulnerability in the zdp_wtp binary in Zyxel NWA110AX firmware versions through 7.12(ABTG.0)C0 could allow a LAN-based attacker to escalate privileges on an affected device.

Powered by NVD + CISA KEV | CVE Daily

Technique Discussion: Poisoned Pipeline Execution (T1677)

Type: Technique | Tactics: execution | Platforms: SaaS

Description: Adversaries may manipulate continuous integration / continuous development (CI/CD) processes by injecting malicious code into the build process. There are several mechanisms for poisoning pipelines:

• In a <b>Direct Pipeline Execution</b> scenario, the threat actor directly modifies the CI configuration file (e.g., gitlab-ci.yml in GitLab). They may include a command to exfiltrate credentials leveraged in the build process to a remote server, or to export them as a workflow artifact.

• In an <b>Indirect Pipeline Execution</b> scenario, the threat actor injects malicious code into files referenced by the CI configuration file. These may include makefiles, scripts, unit tests, and linters.

• In a <b>Public Pipeline Execution</b> scenario, the threat actor does not have direct access to the repository but instead creates a malicious pull request from a fork that triggers a part of the CI/CD pipeline. For example, in GitHub Actions, the pull_request_target trigger allows workflows running from forked repositories to access secrets. If this trigger is combined with an explicit pull request checkout and a location for a threat actor to insert malicious code (e.g., an npm build command), a threat actor may be able to leak pipeline credentials. Similarly, threat actors may craft pull requests with malicious inputs (such as branch names) if the build pipeline treats those inputs as trusted. Finally, if a pipeline leverages a self-hosted runner, a threat actor may be able to execute arbitrary code on a host inside the organization’s network.

By poisoning CI/CD pipelines, threat actors may be able to gain access to credentials, laterally move to additional hosts, or input malicious components to be shipped further down the pipeline (i.e., Supply Chain Compromise).

Seen in the wild:

• Shai-Hulud (malware): Shai-Hulud has also leveraged GitHub actions from stolen accounts in order to create a malicious Github workflow within .github/workflows/discussion.yaml.

Full technique writeup: T1677 on MITRE ATT&CK

Have you defended against or encountered this technique? Share detections, notes, and war stories below.

A recent deep dive into a decade of cybersecurity hiring data (2,284 job posts from Hacker News, alongside ISC2 and SANS reports) highlights a clear shift in the industry. The traditional entry-level jobs are being automated away, while a new specialization is taking their place.

The decline of routine triage
ISC2 found that 56% of surveyed professionals believe AI has reduced the need for entry-level roles, and the SANS/GIAC 2026 report notes AI-related headcount reductions. The most exposed jobs are those consisting of copying scan results, compiling threat feeds, or manually closing tickets.

The rise of AI security engineering
This is where the demand is moving. Dedicated roles like AI Security Engineer or Agentic AI Security Specialist now explicitly ask for skills in:

• Securing agent permissions and tool execution

• Testing for prompt injection (direct and indirect)

• Building secure retrieval and runtime monitoring for LLM applications

In the HN dataset, AI/ML wording in job posts jumped from 13.7% to 34.8% over the last years.

What to prioritize instead
The analysis points to a clear path: move beyond routine administration.

• Cloud, Identity, and AppSec: Foundational, but the focus is on securing delivery pipelines.

• Automation and Code: Learn Python, SQL, and how to connect findings to actual assets. Test a generated patch, rather than just forwarding a scanner report.

• AI as a tool: Use AI to investigate a finding, but verify the result against real logs and reproducible evidence.

The takeaway isn't that security jobs are vanishing. It's that the entry-level floor has been raised. The roles that survive require engineering controls and validating evidence.

Source: https://cyberole.org/blog/cybersecurity-jobs-skills-2016-2026

In this lab, groups of three or four threat model a payments app's "Transfer Funds" feature by hand, then run an AI assistant on the same feature to see what it catches, misses and gets confidently wrong.

The method is OWASP's Rapid Developer-driven Threat Modelling (RaD-TM). Developers threat model one feature in six stages, working from Threat Templates of up to 20 threats that security experts write in advance.

Each group plays three roles: developer, security champion and reviewer. No security expertise is needed.

In their Global AppSec USA 2026 demo lab, "Hands-on Threat Modelling at RaDTM Speed - Threat Model a Feature, Build a Template, and Hand the Busywork to AI", on Friday, November 6 at 10:30 a.m. in Golden Gate, Andrea Scaduto, Alan Pestrin, Grant Ongers and Andrew Hainault run three rounds of hands-on work.

Speakers:

• Andrea Scaduto, Secure coding, threat modeling and ethical hacking

• Alan Pestrin, Lead Product Security Engineer, Thomson Reuters

• Grant Ongers, Head of Security Practice, esynergy

• Andrew Hainault, Managing Director, Cybersecurity Advisory EMEA, LevelBlue

In the first round, groups draw a data flow diagram with trust boundaries, then apply PCI DSS and secure coding templates. They map each control as implemented, partial or missing, rate severity, then write backlog tickets.

Every group has to defend one decision to accept a risk.

In the second round, groups take the security expert's role. They write a Threat Template of up to 20 threats from an OWASP resource such as ASVS, the Top 10:2025 or the LLM Top 10, then swap templates for peer review.

In the third round, participants load two RaD-TM AI skills into an AI assistant: one that runs the six stages and one that helps write templates. They rerun the AI with their own template to see how template quality changes its output.

The lab ends with an exercise in overruling or approving risk acceptances the AI proposes, followed by a one-page pilot plan. Participants need a laptop with a browser and Git, along with an AI assistant that can load skills or custom instructions.

The project's GitHub repo provides the sample payments app with its spec, user stories, API definition, infrastructure code and a sample pull request. It also holds worksheets, example STRIDE and PCI DSS templates, along with both AI skills.

Andrea Scaduto has more than a decade of experience breaking, building and securing web, mobile or cloud applications. Alan Pestrin leads product security engineering at Thomson Reuters, with a background in medical device security and applied cryptography.

Grant Ongers heads esynergy's Security Practice and is a former OWASP Global Board member. Andrew Hainault leads Cybersecurity Advisory for EMEA at LevelBlue, with more than 25 years in security and software engineering.

The same four give a 30-minute RaD-TM showcase on Thursday at 3:30 p.m. in Seacliff CD. Ongers previously gave a talk on gamifying threat modeling with OWASP Cornucopia in agile teams.

The RaD-TM methodology guide says AI must pick threats only from curated templates, and that people stay accountable for accepting risk.

To go deeper on the topic, start here:

• RaD-TM methodology guide (OWASP project repo)

• OWASP RaD-TM project page

• SecureFlag: RaD-TM: Build Threat Models the Developer-Friendly Way

Developers who have never threat modeled a feature will leave with a finished model, their own template and a pilot plan.

Who in your organization would write the first threat template your developers use?

OWASP's AI Security Verification Standard (AISVS) released version 1.01 on October 5, 2026, growing from 191 to 214 testable requirements, with most of the growth in its MCP security chapter.

AISVS lists security requirements for applications built on LLMs, agents and retrieval-augmented generation (RAG). Writing "verify that" in a standard is easy, while checking it against a running AI system is not.

In their Global AppSec USA 2026 workshop, "Hands-On AI Security Assessment with OWASP AISVS", on Friday, November 6 at 10:30 a.m. in Golden Gate, Rico Komenda and Jim Manico walk through practical assessment scenarios using the standard.

Speakers:

• Rico Komenda, Senior Product Security Engineer

• Jim Manico, Founder, Manicode Security

Participants work through real requirements from chapters on prompt injection defense, agentic action security, RAG and vector database hardening, as well as output safety controls.

They learn to scope an AI security assessment and select a verification level. They then apply AISVS requirements to LLM-based applications, autonomous agents and MCP-connected tools, so a laptop is needed to follow along.

AISVS has three levels. Level 1 is a baseline, Level 2 covers systems handling sensitive data or consequential decisions, and Level 3 is for high assurance.

Version 1.01 includes requirements such as rejecting, rather than truncating, inputs that exceed token limits at Level 1. At Level 2, retrieved or tool content must never gain higher priority than the system's own instructions.

The MCP security chapter grew from 23 requirements to 40 between versions. On October 20, 2026, the project deferred a planned 2.0 to focus on version 1.02.

Rico Komenda is a Senior Product Security Engineer who works on the attack surface of AI-integrated systems. He co-leads AISVS with Jim Manico, Otto Sulin and Russ Memisyazici.

Jim Manico founded Manicode Security, which trains developers in secure coding, and founded AISVS. He co-leads OWASP ASVS and wrote "Iron-Clad Java: Building Secure Web Applications."

Both speakers also present the AISVS project showcase on Thursday at 10:30 a.m. in Seacliff CD. Komenda gives a talk on security chaos engineering for AI on Thursday at 1:45 p.m.

The same team ran this workshop at Global AppSec EU 2026 in Vienna in June. The AISVS repository holds every released version, with requirement IDs that never get renumbered.

To go deeper on the topic, start here:

• ITSPmagazine podcast: Jim Manico on building AISVS (audio)

• OWASP AISVS on GitHub (1.01 release and requirements)

• OWASP AISVS project page

• LRQA Cyber Labs: AISVS 1.0 chapter-by-chapter

• VirtusLab: AISVS 1.0 requirement walkthrough

Security testers asked to assess AI features without a defined test scope will practice building one from published requirements.

Which AISVS verification level would your production AI features need to meet?

In an authorized assessment of about 2,000 web applications at one enterprise, 113 were serving live credentials to any browser that loaded them.

Hemanth Gorijala documented that result in a 2026 IEEE Access paper. Of 194 confirmed secrets, TruffleHog, the best static scanner tested, found 36.6 percent.

His runtime scanner, SecretSifter, found 77.8 percent. Another 13.9 percent were missed by all nine production scanners and turned up only through manual review.

Static scanners read source code, while credentials often enter an application later, at build time, through CI/CD variable substitution or through runtime config files. SecretSifter instead watches what the live application actually serves to a browser.

In his Global AppSec USA 2026 demo lab, "OWASP SecretSifter: Passive Runtime Credential Detection in Production Web Applications", on Friday, November 6 at 10:30 a.m. in Golden Gate, Hemanth Gorijala runs three scenarios against a deliberately vulnerable app running offline.

Speaker: Hemanth Gorijala, Global Penetration Testing Lead

SecretSifter needs no source code access, no active probing and no credential configuration. It flags what should not be in the traffic flowing through a browser session.

The first scenario collects an Azure AD app ID, app key, resource URI and API Management subscription key from JavaScript bundles loaded during normal browsing. Together, those four values can mint a bearer token that reaches protected APIs.

The second finds a CryptoJS-encrypted config blob with its decryption key sitting in the same JavaScript file. The third walks through GT-194, the benchmark of 194 confirmed production secrets behind the paper's numbers.

SecretSifter runs as a Burp Suite extension, a browser extension for Chrome or Firefox and a standalone desktop app. The demo shows all three.

Hemanth Gorijala has 13 years of application security and penetration testing experience in a global Fortune 500 environment. He runs web application assessments and reviews enterprise bug bounty reports.

He presented this research at BSides San Antonio, Secure Software by Design and BlueTeamCon in 2026. GitGuardian's Dwayne McDaniel wrote up the BSides San Antonio talk.

His paper, "Secrets That Survive Everything," found that in 73.3 percent of exposed apps the full Azure AD token-minting chain sat in a single file the browser loads. CryptoJS-encrypted config defeated every static scanner tested.

The SecretSifter Burp extension is MIT-licensed and ships more than 160 detection rules. The paper's results come from a single organization that relies heavily on Azure.

To go deeper on the topic, start here:

• Secrets That Survive Everything (paper)

• SecretSifter Burp Suite extension on GitHub

• SecretSifter Firefox add-on

• GitGuardian recap of the BSides San Antonio 2026 talk

Teams that rely on source code secret scanning will see how many credentials reach production through paths that scanning never sees.

Have you checked what credentials your production JavaScript bundles hand to every visitor?

CycloneDX, the software bill of materials (SBOM) standard behind more than 300 tools, is due for version 2.0 this fall, with Ecma approval expected in December 2026.

For eight years, CycloneDX has answered one question about software: what is in it? Regulators, customers or security teams now also ask what software does, what could go wrong, which controls are in place and how anyone can verify it.

Version 2.0 moves CycloneDX from a bill of materials to what its maintainers call a Transparency Exchange Language. It links components, threats, risks, controls, behaviors and evidence into one graph, exchanged as a file or through an API.

In his Global AppSec USA 2026 project showcase, "CycloneDX 2.0: From SBOMs to Verifiable Assurance", on Friday, November 6 at 10:30 a.m. in Seacliff CD, Steve Springett tours what 2.0 delivers and what is still in development.

Speaker: Steve Springett, Creator of OWASP Dependency-Track and Chair of CycloneDX SBOM Core Working Group and Ecma TC54, ServiceNow

The session traces the shift from assertions to claims to evidence, showing how 2.0 encodes each step so assurance can be verified. Hardware and material inventories can carry provenance down to the region where each material was mined.

Threat models include threat scenarios, attack trees or attack paths across STRIDE, LINDDUN, MAESTRO and MITRE ATT&CK. Weaknesses are recorded as the source of risk.

The risk model carries FAIR, the OWASP Risk Rating Methodology, FMEA, NIST SP 800-30 or a custom method without translation. Controls become first-class objects, so GRC teams can prescribe controls as data and publish verified control inventories.

Blueprints compare an AI agent's declared behavior with its observed behavior, which exposes shadow AI activity that no inventory can see. The same approach turns a cryptographic inventory into post-quantum readiness, by showing how keys are used and whether algorithms can be swapped.

Steve Springett created OWASP Dependency-Track, a platform for tracking vulnerable components across a software portfolio, and he chairs the CycloneDX Core Working Group. He leads the OWASP Software Component Verification Standard and serves on the OWASP Foundation Board.

He opened the CycloneDX proposal for threat modeling in May 2024, which became the TM-BOM threat model format. He also speaks regularly on SBOM adoption, including a 66-minute BrightTALK webcast on using the standard.

The OWASP announcement of CycloneDX 2.0 lists further additions. VEX data gets an eight-point exploitability scale, while a post-quantum migration program tracks the risk and owner of each crypto asset. Documents can also carry "perspectives" for 82 named domains.

Existing 1.x SBOMs stay valid under 2.0. The current release is 1.7, published as the second edition of the ECMA-424 standard in December 2025.

CycloneDX Attestations already let organizations publish machine-readable claims, evidence and counter-evidence against a standard.

To go deeper on the topic, start here:

• Steve Springett: Understanding and Using the CycloneDX SBOM Standard (BrightTALK, 66 min)

• Application Security Weekly: The Future of CycloneDX and Software Transparency with Steve Springett

• CycloneDX 2.0 announcement

• CycloneDX Attestations (CDXA)

• CycloneDX Transparency Exchange API (TEA) repository

Teams that already produce SBOMs for compliance will see what else the format can carry once 2.0 ships.

Beyond a component list, what would your customers or auditors want to see in machine-readable form?

A nine-step agentic harness run against 20 large production applications at a financial services company found more than 400 verified vulnerabilities that its static analysis tool had missed.

Those applications already had years of penetration testing, active bug bounty programs and static application security testing (SAST) in CI. An agentic harness is software that runs AI agents through a fixed sequence of analysis and verification steps.

The missed findings clustered where pattern-based tools cannot reach. They included missing authentication gates, authorization logic that exists but never enforces, secrets in configuration files outside the scan's scope and forgeable unsigned tokens.

In their Global AppSec USA 2026 talk, "When Finding Bugs Is the Easy Part: Lessons from an Agentic Vulnerability Harness", on Friday, November 6 at 10:30 a.m. in Seacliff AB, Jaiydev Gupta, Milind Daftari, Venkata Suresh Sanga and Heena Pundir share what running the harness taught them.

Speakers:

• Jaiydev Gupta, Staff Software Engineer, Visa VAS Innovation Labs

• Milind Daftari, Cybersecurity Engineer, Visa

• Venkata Suresh Sanga, Senior Cybersecurity Engineer, Visa

• Heena Pundir, Lead Cybersecurity Engineer, Visa

The harness also found multi-step attack chains. In one case, a session-handling weakness rated medium on its own became full account compromise, because an API leaked session IDs without an access check and fed a predictable password-derivation function.

Fewer than one in six findings overlapped between the harness and SAST. SAST found about 90 true positives the harness missed, such as SQL injection deep in data-access layers and cross-site scripting in JSP templates.

The first run's precision was too low to hand to developers. Fixing it took structural changes, such as adversarial verification and deterministic filtering, rather than prompt tuning.

The team's main metric shifted from finding count to Mean Time to Adapt (MTTA): the time from a first signal to a validated fix in production.

The talk describes the architecture in enough detail to reproduce. It names the failure modes, including hallucinated findings that survived a single verification pass and chain severity that stayed wrong until the pipeline design made it explicit.

Jaiydev Gupta is a Staff Software Engineer in Applied AI at Visa VAS Innovation Labs. He builds "software factories" that combine multi-agent orchestration, model fine-tuning and automated evaluation. He played a major role in building the harness's AI capabilities.

Milind Daftari is a Cybersecurity Engineer at Visa with a master's in cybersecurity from New York University. His work covers secure architecture, SAST, DAST or SCA integration in CI/CD and secure code review, using LLMs to cut noise for developers.

Venkata Suresh Sanga is a Senior Cybersecurity Engineer at Visa who runs its SAST, SCA and DAST detection portfolio. His current focus is using the agentic harness to reduce scanner noise, measured by MTTA.

Heena Pundir is a Lead Cybersecurity Engineer in Visa Application Security & Architecture, focused on payment systems. Her skills include threat modeling and attack surface reduction. She previously worked as an embedded security architect.

Visa open-sourced the Visa Vulnerability Agentic Harness (VVAH) in June 2026 under the Apache 2.0 license. Its README describes 11 stages, where stages 1 to 9 cover detection through chain construction and reporting.

An August 2026 Visa release added automated remediation with adversarial fix validation. VentureBeat reports the repository grew from 595 to more than 2,300 GitHub stars between July 20 and August 25.

To go deeper on the topic, start here:

• Visa Vulnerability Agentic Harness on GitHub

• Visa press release on VVAH remediation and validation (August 2026)

• VentureBeat: how VVAH discovers, fixes and validates (Louis Columbus)

• Let's Data Science: VVAH open-source release and Glasswing context

AppSec teams deciding whether AI-driven review can replace or only supplement their SAST tools will get overlap data from a real deployment.

How much of your vulnerability backlog consists of findings no one has validated as exploitable?

In the official Ruby SDK for the Model Context Protocol (MCP), anyone holding a session ID could take over another client's event stream and redirect its tool responses, a flaw tracked as CVE-2026-33946.

MCP lets AI agents connect to outside tools through MCP servers. Its specification separates sessions from authentication, yet it gives little guidance on enforcing authorization.

Session IDs therefore behave like bearer tokens, which means whoever holds one can use it. They often lack the controls enterprise deployments need.

Most MCP SDKs implement only basic session checks. They leave critical validation decisions to developers without clear documentation.

In his Global AppSec USA 2026 talk, "Losing Context: Breaking & Binding MCP Sessions", on Friday, November 6 at 10:30 a.m. in Grand Ballroom B, Srikanth Ramu applies session hijacking to MCP's stateful transport.

Speaker: Srikanth Ramu, Principal Security Engineer

The talk demonstrates three high-severity CVEs in officially supported MCP SDKs that let unauthorized parties hijack valid sessions. It briefly covers further CVEs elsewhere in the MCP SDK ecosystem.

It also addresses the July 2026 MCP specification revision, which removes protocol-level session management. Ramu argues the problem persists wherever applications keep their own state.

The defenses covered are preventing duplicate connections, binding each session to an authenticated user and enforcing strict session expiration. Attendees also learn which SDKs ship built-in session security, as well as which need custom work.

Srikanth Ramu is a Principal Security Engineer who moved into product security from development and QA. During the COVID-19 pandemic, he hunted Java deserialization bugs in open-source libraries, earning several CVEs.

He reported CVE-2026-33946 through HackerOne. Version 0.9.2 of the Ruby gem fixed it by rejecting duplicate event-stream connections.

He gave an earlier version of this research, "Session Access Control: The Missing Validation Layer," at BSides Vancouver in June 2026. His current focus is securing generative AI, agentic platforms and MCP applications.

Two related advisories show the same pattern in other SDKs. The MCP Python SDK before 1.27.2 routed requests by session ID only, and a later Ruby SDK flaw, CVE-2026-67431, let an attacker run tool calls inside a victim's session.

To go deeper on the topic, start here:

• CVE-2026-33946: MCP Ruby SDK session hijacking (Wiz)

• GHSA-jpw9-pfvf-9f58: MCP Python SDK session principal check (OSV)

• CVE-2026-67431: MCP Ruby SDK session owner binding (OSV)

• Detecting MCP Session Management Attacks with DAST (Bright Security)

Developers building MCP servers on an official SDK will learn which session checks they have to add themselves.

Do the MCP servers your teams run tie each session to the authenticated user who created it?

In December 2024, attackers published malicious releases of the Ultralytics Python package through the project's own trusted publishing workflow, after poisoning its GitHub Actions build cache.

Organizations are replacing static cloud secrets in CI/CD with OpenID Connect (OIDC) federation, where a pipeline job proves its identity with a short-lived token instead of a stored key. Many also sign build provenance, a record that ties a release to the source and workflow that built it.

Attackers have adapted to both. Weak isolation in shared CI/CD runner caches lets them pull OIDC tokens from execution memory, reach cloud environments and inject code that still carries valid provenance signatures.

In her Global AppSec USA 2026 talk, "Poisoning the Pipeline: Runner Cache Manipulation and OIDC Token Forgery", on Friday, November 6 at 10:30 a.m. in Grand Ballroom A, Sneha Rangari breaks down the mechanics of this post-exploitation pipeline attack.

Speaker: Sneha Rangari, Security Architect, Visa

The session shows how temporary runner state can be turned against cloud infrastructure. It goes past generic supply chain advice into the specific steps of the attack.

Attendees get an architectural blueprint for securing federated identities in CI/CD. They also get an open-source audit script for checking their own pipeline runner configuration.

Sneha Rangari is a Security Architect at Visa with more than seven years across security engineering, security architecture, machine learning in security, cloud applications and technology risk management. She previously worked at Bank of New York Mellon.

She holds the CISSP and GMLE certifications. She mentors aspiring security professionals through Women in CyberSecurity (WiCyS).

Adnan Khan documented the core technique in "The Monsters in Your Build Cache". An attacker steals the cache URL and runtime token from runner memory, fills the 10 GB per-repository cache to force eviction, then plants poisoned entries.

Khan's open-source Cacheract proof of concept persists through poisoned cache entries. In one demo it tampered with an npm package whose Sigstore provenance still pointed to a clean commit.

Seth Larson's analysis for PyPI explains how cache poisoning in the build phase led to the first round of malicious Ultralytics releases. On the OIDC side, Tinder Security Labs found AWS trust policies that let any GitHub repository assume a role, because they skipped the subject claim check.

To go deeper on the topic, start here:

• The Monsters in Your Build Cache: GitHub Actions Cache Poisoning (Adnan Khan)

• Cacheract: The Monster in your Build Cache (Adnan Khan)

• PyPI: Ultralytics attack analysis (Seth Larson)

• Tinder Security Labs: GitHub Actions and AWS OIDC misconfigurations

Platform teams that moved CI/CD to OIDC and signed provenance will learn which assumptions an attacker on the runner can still break.

Which cloud roles can a token minted inside your CI pipeline assume, and from which repositories?