Published file metadata, source observations, indicators, and research history in one bounded catalog.
2,400+Reachable catalog records
65 / 100Current catalog page
24Maximum records per page
0Samples downloaded by this page
Feed collection status
Sources represented on this page. Publication and observation dates describe the content; successful batch dates describe local collection. A recent batch does not certify complete coverage or current provider availability.
intelligence_src_cd638cf167c7c119d6Recent successful batchLast successful batch: Last attempt:
intelligence_src_cdcffed32aa78fd61fRecent successful batchLast successful batch: Last attempt:
Stale means older than twice the recorded collection interval, with a minimum of one hour; without an interval, the threshold is 24 hours. Cached content remains available while a feed is stale, paused, or unverified.
2,400+ MATCHING RECORDSMETADATA ONLY / SOURCE ATTRIBUTION PRESERVED
For the third week running, Citrix has issued a critical security warning to customers managing their own NetScaler ADC and Netscaler Gateway instances, this time warning of a memory overflow vulnerability enabling denial of service or remote code execution. This week’s vulnerability affects ADC and Gateway when configured as a SAML (Security Assertion Markup Language) identity provider (IdP); older versions are also vulnerable when configured as a SAML service provider (SP), Citrix said in an advisory about the vulnerability, which it is tracking as CVE-2026-107406. Citrix rated the vulnerability critical, with a CVSS v4.0 score of 9.5. It said it was “not aware of any unmitigated exploits of this vulnerability.” Nevertheless, it encouraged affected customers to upgrade to patched versions as soon as possible: 13.1-64.29 or later for the 13.1 series, and 14.1-73.46 or later for the 14.1 series of ADC and Gateway, and 13.1.37.283 or later for ADC 13.1-FIPS. Or 13.1-NDcPP. Citrix’s recent run of bad news began on Sept. 27, a Sunday, when it advised users of NetScaler ADC and Gateway to take their systems offline and patch two critical unauthenticated remote code execution vulnerabilities immediately as they were both under active attack, prompting one security researcher to warn, “Monday will be too late.” More flaws turned up last week including another memory overflow vulnerability (CVE-2026-88779), this one rated 8.7 on the CVSS 4.0 scale. Citrix said it was being actively exploited to cause denial of service. Citrix also released a new version of NetScaler ADC and Gateway, 14.1-60.58, that week, patching a critical memory overread vulnerability previously reported as CVE-2026-3055. Whether it’s memory overflows or memory overreads, when it comes to fixing security vulnerabilities in its NetScaler products Citrix seems to have a memory problem. This article first appeared on Network World.
First reported Oct 09, 2026 14:28 UTCCatalog metadata updated Oct 14, 2026 03:27 UTCOpen evidence record
Year after year CISOs see the volume, velocity, and sophistication of attacks increase. They also see their attack surfaces expand and increase in complexity. Advances in artificial intelligence and the rapid growth of AI use in business are also impacting the security agenda, introducing novel attacks, broadening the attack surface to include AI infrastructure, and presenting governance and security control challenges and complications — especially as agentic systems come online. As a result, 68% of security leaders report that their roles have become more stressful over the past five years, according to the 2026 State of Cybersecurity survey from ISACA, with 71% of CISOs citing the increasingly complex threat landscape as their main stressor, up from 63% in 2025. Moreover, the introduction of Mythos-class AI models has 50% of CISOs considering exiting the profession entirely, according to a recent survey from Absolute. To tackle this increasingly complex and intense security environment, security leaders must sharpen their strategies — and their teams’ skills — around the most pressing issues they and their CISO colleagues are facing today. To help with that, we spoke with security chiefs and cyber experts to identify the seven biggest issues CISOs need to address, with insights on how to tackle the challenges. 1. Preventing compromise — with increased emphasis on resilience and recovery Although CISOs are increasingly taking on governance responsibilities and business risk mandates, broadening their remit, Kyle McMillan, chief cybersecurity officer at Siemens USA, says all the work in the security organization is still “framed in the context of preventing a compromise.” It’s a monumental task, McMillan says, as there’s no one formula for the right defense that will work for every CISO. Rather, CISOs must know the specific risk profile of their organizations, the specifics of their IT environment, and the general threat landscape, as well as any threats particular to their industry — and then use all that to formulate a unique plan of defense based on the resources available. “And there are always trade-offs to be made,” McMillan adds. While it’s true that thwarting attacks as much as possible and minimizing the damage in the event of a successful breach has always been job No. 1 for CISOs, research shows it’s one they continue to struggle with. The State of Incident Response Readiness, a 2026 report from incident response company Sygnia, found that 73% of CISOs weren’t fully ready for a major cyberattack. That — and the rise of AI-assisted attack volumes and speed — is contributing to a mindset shift from prevention to resilience. Yes, prevention remains job No. 1, but ensuring business continuity and resilience in the event of an incident is becoming a key emphasis and addition to CISOs’ playbooks. That means honing incident response plans, conducting more relevant tabletop exercises, and sharpening team operations to accelerate cyber recovery. According to Foundry’s forthcoming Security Priorities Study, 69% of security leaders are currently undertaking this shift. 2. Leading a security program aligned with the organization’s specific needs One of the biggest issues CISOs continue to face is accurately assessing their organization’s processes, infrastructure, and risk profile and then building a program tailored to their unique security requirements, says Ira Winkler, veteran cybersecurity leader and now CEO and program director of CruiseCon, which offers professional education for security leaders. “CISOs are not monoliths,” Winkler points out. Some CISOs struggle to patch all the critical vulnerabilities in their environments fast enough, whereas others struggle to tackle essential work with the staff and budgets they have; still others find themselves falling short in taking a strategic approach to their role. What this often
First reported Oct 12, 2026 08:25 UTCCatalog metadata updated Oct 14, 2026 03:27 UTCOpen evidence record
GitLab just fixed a max-severity vulnerability that could allow unauthenticated attackers to execute arbitrary code on its servers. The company released a fix on Monday, alongside patches for five other high-severity flaws affecting its source code management and continuous integration and delivery (CI/CD) platform. The vulnerability, tracked as CVE-2026-97229, was fixed in versions 19.4.2, 19.3.5, and 19.2.8 of its Community Edition (CE) and Enterprise Edition (EE), according to a patch advisory. The company urged administrators of self-managed installations running affected versions to upgrade immediately. GitLab.com is already running the patched version, while GitLab Dedicated customers do not need to take action, the company said in the advisory. The release also addresses vulnerabilities that could expose protected environment variables, allow unauthorized pipeline execution, and enable attackers to inject crafted content into AI agent instructions. The fixes span both CE and EE, with some issues affecting only the Enterprise Edition. “When no specific deployment type (omnibus, source code, Helm chart, etc.) of a product is mentioned, it means all types are affected,” GitLab added. Critical regex flaw could enable unauthenticated code execution GitLab described CVE-2026-97229 as an integer overflow issue in the platform’s CI/CD regular expression compiler. Under certain conditions, insufficient validation of regular expressions could have allowed an unauthenticated attacker to execute arbitrary code on the GitLab server by supplying a specially crafted regular expression in a CI/CD configuration. The vulnerability affects GitLab CE and EE versions from 19.2 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2. It carries a maximum CVSS score of 10.0 for potentially allowing remote code execution without authentication, with impacts on confidentiality, integrity, and availability across security boundaries. GitLab credited researcher Johan Carlsson with reporting the flaw through its HackerOne bug bounty program. Pipeline permissions and AI agents in the crosshairs Among the five high-severity vulnerabilities, CVE-2026-92883 could allow an authenticated user to execute arbitrary JavaScript in other users’ browser sessions through a specially crafted repository. The cross-site scripting flaw resulted from improper sanitization of HTML attributes in syntax-highlighted output and carries a CVSS score of 8.7. Two other flaws target pipeline security. CVE-2026-16301 (CVSS 8.5) could have allowed users with the Developer role to execute CI/CD pipelines on protected branches without authorization. CVE-2026-14814 (CVSS 8.2) potentially enabled attackers to poison cached responses for raw repository files, potentially causing targeted pipelines to execute malicious content and access protected environment variables. The remaining issues affect scheduled pipeline execution and GitLab Duo. CVE-2026-81839 (CVSS 7.7) could have allowed authenticated users to run arbitrary pipelines in a transferred project with the new group’s privileges. Another, CVE-2026-96893 (CVSS 7.3), could have allowed an authenticated user to inject crafted content into AI agent instructions, potentially causing unintended command execution attributed to other users. GitLab said it plans to make vulnerability issue details public 90 days after the release in which they were patched. Administrators should therefore prioritize the applicable security updates rather than wait for further technical disclosure. The release also fixes several low-to-medium severity vulnerabilities affecting GitLab Pages, Kubernetes proxying, GraphQL APIs, merge requests, custom roles, the package registry, and repository and project import functions.
First reported Oct 13, 2026 11:42 UTCCatalog metadata updated Oct 14, 2026 03:27 UTCOpen evidence record
Details from an FBI investigation into the ongoing FortiBleed attacks reveal that victims could be locked out of their own firewall even as attackers remain logged in. After gaining access to a backend server left exposed by the attackers, the FBI and US Secret Service have shared new details of an operation that has already affected more than 80,000 devices worldwide. The server gave investigators a look at the infrastructure behind the operation, including systems used to process stolen credentials, crack password hashes, and identify potential targets. The operators were also found ranking organizations based on their revenue and network structure, the FBI said in an advisory. “FortiBleed isn’t a vulnerability story anymore,” said Muhammad Yahya Patel, vCISO, cybersecurity advisor EMEA at Huntress. “It’s a persistence story. The credentials were taken months ago. The question every organization needs to answer is whether they’re still being used right now.” Attackers have created administrative accounts, enumerated Active Directory environments, and used compromised credentials for lateral movement, the FBI added. Access obtained through the campaign has also been offered to ransomware affiliates, including INC/Lynx and Payload ransomware. Attackers can lock defenders out The newly disclosed lockout capability is a more immediate operational risk for affected organizations. The FBI said some victims may lose access to their FortiGate devices when attackers delete or change the passwords of existing accounts. During an intrusion, attackers create new accounts that were not previously present on the device. In some cases, they then delete existing accounts, preventing organizational persistence and attempting to move laterally through the environment. “When you no longer have access to your own firewall, you cannot just apply a software patch and move on,” said Ben Bernstein, manager, cybersecurity advisors team at Huntress. “These attackers know organizations will have to physically factory reset and rebuild the hardware before the encryption starts.” FBI’s newly published account names and infrastructure indicators can help organizations investigate potential compromise. The agency recommended reviewing Fortinet accounts and configurations for unauthorized changes, checking firewall, VPN, authentication, and domain controller logs for suspicious activity, and looking for unknown or unexpected REST API keys that could provide attackers with automated access to FortiGate systems.Terminating active administrative and VPN sessions, resetting Fortinet administrative and VPN credentials, enforcing phishing-resistant MFA, and using PBKDF2 for admin credentials were also recommended. Hackers rented GPUs to crack passwords Among the newly disclosed details are the use of rented GPU infrastructure for password cracking, Hashcat and Hashtopolic to distribute cracking jobs, and tooling to validate and prioritize recovered credentials. “Attackers are stealing configuration files, cracking password hashes offline on their own hardware, and logging in on the first try without generating a single failed login alert,” Bernstein pointed out. “Targeting edge devices like VPNs and firewalls is nothing new, but this FortiBleed campaign stands out because of the contrast between the silent initial access and the aggressive takeover that follows.” The infrastructure uncovered by investigators included command-and-control (C2) servers, relay nodes, and scanning systems, with several IP addresses identified as being used for brute-force activity or successful authentication with compromised accounts. The FBI has published those indicators to help organizations investigate potential compromise, while cautioning that some infrastructure may have been dynamically or temporarily assigned. Evidence on how the operators maintained access after an initial compromise was also found.
First reported Oct 08, 2026 11:44 UTCCatalog metadata updated Oct 14, 2026 03:27 UTCOpen evidence record
When quantum vendor IonQ on Sunday announced a $1.2 billion all stock deal to take over cybersecurity vendor Elisity, it spoke of a near-term future where enterprise quantum cybersecurity needs will move beyond replacing to-be-outdated encryption. The acquisition brings together IonQ’s post-quantum cryptography (PQC) and quantum key distribution (QKD) capabilities and Elisity’s enterprise Zero Trust technology platform, IonQ said in a news release. “On a combined basis, IonQ will benefit from an expanded cybersecurity platform that both uncovers and protects against present LLM and emerging quantum threats.” The news release pointed to more than 100 global Elisity customers, and said IonQ expects to receive “expanded channels to bring its PQC, QKD and quantum computing offerings to market for both enterprise and government networks, opening up the more than $10 billion microsegmentation market.” Analysts and consultants saw the move as having potential, but pointed to technical challenges of truly integrating the product lines. “What IonQ gets today is access. Dividing the headline price by those deployments puts it at about $13 million each,” said Frank Dickson, principal analyst at Dickson Research. “That is a steep price for a Rolodex, if you will. Paying in its own stock makes the price easier for IonQ to swallow.” Dickson said that Elisity, which was founded in 2019, has focused on zero trust microsegmentation. “In plain terms, it limits each user, device, workload, and AI agent to only the network connections it needs. An attacker who gets in cannot roam freely,” Dickson said. “Its software enforces those rules over the network a customer already owns, without new hardware. That is a solid business aimed at attacks happening today. Little of it has anything to do with quantum.” Justin Greis, CEO of consulting firm Acceligence, added that the pairing could be effective for enterprise CISOs, assuming the internal tech integration issues can be overcome. “Bringing those capabilities together could create a compelling platform, particularly as enterprises contend with increasingly complex environments, autonomous AI agents, and a growing number of non-human identities,” Greis said. “But these are different layers of protection, and integrating them into a cohesive offering will require meaningful engineering and execution.” Brian Jackson, a principal research director at Info-Tech Research Group, also noted that part of the move speaks to IonQ’s need for revenue while quantum is ramping up. “IonQ’s core quantum computing business is still years from broad commercial payoff, so this reads as a move to build revenue in adjacent security markets where customers are already buying,” he said. “The quantum link is thinner than the announcement suggests. Post-quantum cryptography runs on classical systems, so migration depends on cryptographic inventory and crypto-agility, not quantum computing expertise.” Paul Smith-Goodson, VP/principal analyst at Moor Insights & Strategy, agreed that the potential benefits from the acquisition are real, but he added that quantum requirements from the US government are also a key factor. “At the architectural level, integrating Elisity with IonQ’s PQC and QKD establishes an end-to-end defense capable of neutralizing future CRQC [Cryptographically Relevant Quantum Computer] threats,” Smith-Goodson said. “Elisity also hands IonQ an immediate, established enterprise sales pipeline of trusted CISO relationships. That will allow IonQ to cross-sell its broader quantum portfolio and capitalize on federal PQC migration mandates.”
First reported Oct 14, 2026 03:21 UTCCatalog metadata updated Oct 14, 2026 03:27 UTCOpen evidence record
There’s an old leadership fantasy that goes something like this: The CISO surveys a sprawling technology estate, discovers 11 tools doing the work of four, calculates the licensing savings, selects a shiny new strategic platform and declares that consolidation has begun. Six months later, all 11 tools are still running. The new platform is now number 12. I’ve seen variations of this throughout my career, from financial services to media to technology companies. At CME Group, I eventually gave myself an unofficial title: chief decommissioning officer. The job was considerably less glamorous than the acronym suggested. I had to find technology that had overstayed its welcome, identify who believed they still owned it, determine who actually depended on it and, occasionally, put a bullet in its head. Buying technology is easy. Killing technology is hard. Tool sprawl is rarely just a technology problem but rather an organizational psychology problem. The industry’s solution has traditionally been consolidation. Buy a platform. Standardize the stack. Reduce vendors and centralize procurement. While all sensible ideas, consolidation efforts routinely stall somewhere between the PowerPoint slide and production. Why? Because changing the toolset is easy. Whereas changing mindset is far more difficult. You cannot Jedi mind trick an engineering team Executives like what is called the “message from the top.” The CEO says security matters. The CIO says everyone will standardize. The CISO announces the strategic platform. Procurement renegotiates contracts. Meanwhile, Gartner produces a quadrant that reassures everybody that the chosen vendor inhabits the correct geometric region. All is well in the world of golf course nepotism. Then reality arrives. A developer says the new scanner takes 12 minutes longer. A marketing manager has a revenue-generating legacy API they depend on. Exception requests have been filed for several years to allow this tool to continue to exist despite the packages supporting it being end-of-life and receiving no security updates. This is where the “message from the middle” matters. Transformation does not happen exclusively in boardrooms and fusion teams. It happens in the layer of engineering managers, architects, product owners, security engineers and operations leaders who determine whether the policy announced upstairs becomes the behavior practiced downstairs. Every layer of the org chart is ostensibly trying to do the right thing and make things better. But top-down politics and bottom-up initiatives seldom find one another standing on common ground. Ignore the middle layer of the org chart and your consolidation project becomes a rather expensive exercise in shelfware. This is something I learned working in European organizations, where consensus building carries more organizational weight than the command-and-control instincts common in American corporations (the Nike-inspired management philosophy of “Just Do It!”). You may have the authority to make a decision without possessing the organizational permission (or “rubber meets the road” context) required to make it stick or worthy of implementation. Good chief decommissioning officers need a mixture of Jedi and Machiavellian skills. We need persuasion, coalition building, incentives, selective pressure and occasionally the ability to convince people that the idea you desperately need them to support was their idea all along. These are, in fact, the droids you’re looking for. Every tool comes with an identity The Star Wars metaphor becomes more useful when we stop thinking of security products as software. Modern security tools have volition and intent. They have: API keys Service accounts OAuth grants Cloud permissions GitHub access tokens CI/CD integrations Slack bots Webhooks Database credentials Kubernetes roles Machine identities and, increasingly, AI agent
First reported Oct 12, 2026 12:19 UTCCatalog metadata updated Oct 14, 2026 03:27 UTCOpen evidence record
Throughout this year, Amazon Web Services (AWS) has repeatedly had to patch autonomous agent security holes, which have then reemerged in slightly different forms, according to cybersecurity researchers at Palo Alto Networks’ Unit 42 and at Zenity Labs. But the problem is not with AWS, which seems to be reacting quickly to address security reports, as much as it is with the essential nature of autonomous AI agents and the difficulty in controlling those agents. The fact that a hyperscaler with Amazon’s massive resources can’t seem to get ahead of the problem illustrates the agentic challenge for all enterprise IT and cybersecurity executives. AgentCore issues On September 18, 2026, for example, Palo Alto Networks’ Unit 42 cybersecurity researchers reported an issue “where using default configurations in AWS AgentCore Harness could allow attackers to steer an agent’s actions through prompt injection to exfiltrate plaintext credentials managed by AgentCore Identity.” The description of the issue revealed in the report illustrates the quintessential agentic flaw: the very access that allows agents to perform their functions also creates a major security risk. “The harness’s own built-in shell tool, which is enabled by default, reaches into the same memory space where credentials are resolved to plaintext,” the report explained. “The built-in tools are a big part of what makes the harness so autonomous and productive. The agent can write files and run code to get real work done. But the same reach that makes the built-in tools useful makes them dangerous when people leave them on unintentionally.” “We’ve found that the shell tool runs as root inside the harness, so the moment an attacker gets the agent to run a command, that command inherits the same root access,” it added. “Nothing has to be misconfigured for this to happen. It is the out-of-the-box state.” The Unit 42 report said that Amazon’s response was ambiguous about whether it had actually plugged that hole: “We disclosed this finding to AWS. AWS reviewed and closed the report as informative under the AgentCore shared responsibility model,” it noted. Several months earlier, on April 7, Unit 42 had also alerted AWS to a different path to credential exfiltration. In its description of that issue, it said it had found a critical security regression in which the AgentCore Runtime used a microVM Metadata Service (MMDS) that lacked session token enforcement. “Prior to our disclosure and AWS’s fixes, this configuration could have allowed an attacker to exploit standard web vulnerabilities, such as server-side request forgery (SSRF), to directly extract sensitive credentials, putting the entire environment at risk,” Unit 42 wrote at the time. Today Zenity Labs published its own report, an advance copy of which it provided to CSO, detailing its findings about AWS agents that surrendered credentials to an attacker who asked for them. Zenity was able to get an agent to return a full set of temporary STS credentials: an access key ID, a secret access key, and a session token belonging to the agent’s execution role. “These credentials aren’t scoped to the sandbox. We exported them onto our own machine, outside AgentCore entirely, and confirmed they were live,” the report said. The agent delivered data that included ECR read permissions, “so we authenticated to the registry and pulled the image. From there, the agent’s source code, its dependencies, and whatever its developers baked in were ours to inspect, as root,” the report said. “At this point, a reasonable reaction is ‘So don’t give agents a raw HTTP tool.,’” Zenity noted. “That doesn’t help. The isolation failure is at the platform level, not the tool level, so anything that can generate outbound traffic reaches IMDS just the same. We reproduced the identical result through several tools, including Strands’ built-
First reported Oct 08, 2026 13:05 UTCCatalog metadata updated Oct 14, 2026 03:27 UTCOpen evidence record
Lightwell, the open-source security initiative set up by IBM and Red Hat, has identified more than 400 previously undiscovered vulnerabilities in widely used Java libraries — and now the companies are inviting customers to submit their own code dependencies to a new service, Lightwell Clearinghouse, for review. They’ll be looking for bugs such as the critical sandbox bypass in Java template engine Thymeleaf, with a CVSS score of 9.1, discovered in April. “AI agents shifted the threat landscape overnight, exploiting old dependencies at machine speed. Finding those bugs is only half the battle: the real work is backporting fixes directly into active production apps so customers do not have to pick between security and uptime. Finding and neutralizing 400+ novel vulnerabilities so quickly shows how fast Lightwell can move,” said Gunnar Hellekson, vice president and general manager of Lightwell. IBM and Red Hat announced in May that they would commit 20,000 engineers and $5 billion to the Lightwell project, combining their open-source engineering expertise, Red Hat’s community relationships, and AI-assisted engineering workflows. Their goal is not just to identify security issues, but also to introduce remediation software to address them. Lightwell is not the only player in town when it comes to identifying and fixing Java vulnerabilities. Azul has introduced free vulnerability risk assessment for Java Virtual Machines. The company said it can address the blind spots that autonomous AI-powered exploitation tools, like Mythos, are able to find. This article first appeared on InfoWorld.
First reported Oct 09, 2026 16:09 UTCCatalog metadata updated Oct 14, 2026 03:27 UTCOpen evidence record
The owner of a ransomware remediation company is facing trial for defrauding customers. Zohar Pinhasi, also known as “Zack Silver” and “Zack Green,” has been arraigned in New York on wire fraud charges for allegedly defrauding clients of his ransomware remediation company, MonsterCloud. Pinhasi falsely claimed he could recover documents encrypted by ransomware without paying a ransom, according to district attorney Joseph Nocella. “The defendant re-victimized his clients while extracting a hefty profit for himself,” Nocella said. MonsterCloud claimed to offer an alternative to paying the ransom. Its website said that, thanks to its decryption techniques, “our team specializes in helping businesses recover their data without succumbing to ransom demands.” However, the indictment alleges that rather than using any technology, Pinhasi simply paid the cybercriminals in exchange for a decryption key with which MonsterCloud employees would then an attempt to unlock their clients’ files. It is alleged that Pinhasi typically charged clients a fee that was substantially higher than the ransom payment. For example, in 2023, he made a payment of $8,200 to a cybercriminal while charging a client $150,000. There may be several reasons why clients chose to use MonsterCloud. US government advice (echoed by other governments) is not to pay ransoms as it may encourage more attacks, and victims may not get their data back. In addition, in some cases, if the attackers are from a country or group subject to trade sanctions, making a payment may actually be illegal, leaving the victim facing criminal charges. There may be other factors at play. “Cases vary; sometimes negotiators simply overcharge for their services. In other cases, they may inflate the final amount, saying, for instance, that 50 percent extra is to ensure a third-party validation of secure data erasure or something similar that the client would buy,” said Ilia Kolochenko of cybersecurity company ImmuniWeb. He warned that there were several techniques being used to extract additional money from ransomware victims. “Some will be contacted by fake law enforcement agencies, which typically promise to find and arrest the hackers, but also mention the victim’s civil liability for the data breach and ask to prepay a bond for an eventual regulatory fine. Other victims may be contacted by fake cybersecurity companies, which claim that they have already found their stolen data on the Dark Web and ask for money to ‘securely erase’ the data from the dark web to avoid bad publicity and regulatory sanctions,” he said. Similar cases have come to court recently, said Kolochenko, one in July involving a Florida business and another targeting a Latvian national in May.
First reported Oct 09, 2026 15:44 UTCCatalog metadata updated Oct 14, 2026 03:27 UTCOpen evidence record
Anthropic is expanding its Cyber Verification Program to give more security teams access to advanced cyber capabilities with reduced safeguards on its most advanced AI models. The expanded program has three access tiers based on the type of cybersecurity work an organization is authorized to perform. The tiers cover defensive security work, authorized red teaming, and testing of systems that could affect public safety or financial markets. “Defenders also need access to the best tools and most powerful capabilities to secure their systems,” Anthropic said in its announcement. The company said its generally available models use conservative cyber safeguards that block most cyber attacks. Anthropic said the safeguards are intended to limit harmful activity while it works to reduce false positives affecting secure coding. The expanded program gives verified security organizations access to Claude Opus 5.5, Claude Sonnet 5.5, and Claude Mythos 5.1, as well as future models, with different levels of cyber restrictions. From Glasswing to CVP Anthropic’s new program combines two initiatives it has operated over the past six months: Project Glasswing and the earlier Cyber Verification Program. Project Glasswing gave selected organizations working to secure critical software access to Claude Mythos. The existing CVP gave vetted security teams access to Claude Opus and Claude Sonnet models with reduced safeguards. “The changes we’re making to our Cyber Verification Program today are intended to extend the impact of Project Glasswing to a much larger number of cyber defenders,” the statement added. Under the expanded program, existing Glasswing members will move to the Specialized Access tier and will not need to seek approval again for their current models, the statement added. Defense Access tier is aimed at defensive work such as security operations, incident response, malware reverse engineering, and vulnerability analysis and validation. Red Team Access adds authorized penetration testing and red-team operations. Users can test only systems they are authorized to assess, Anthropic said. Specialized Access has the fewest cyber restrictions and is reserved for a limited set of verified organizations authorized to test systems such as flight operating systems, power grids, telecommunications networks, interbank transfer infrastructure, and government administrative networks. Anthropic said it reviews organizations seeking Specialized Access in collaboration with the US government. Testing the tiers Anthropic tested the different access levels using CyScenarioBench, an evaluation designed to measure whether AI models can plan and execute multistage cyber operations. The company ran Claude Opus 5.5 through 10 challenges, with five attempts at each challenge for every access tier. Without CVP access, all 50 trials were blocked at the first prompt, Anthropic said. Under Defense Access, 46 of the 50 trials were blocked at some point, while four succeeded. Under Red Team Access, Anthropic said none of the 50 trials was blocked, and Claude completed 34. The company said that was equivalent to its 67.6% success rate when no safeguards were applied. Sakshi Grover, research director at IDC, said the evaluation should be viewed in context because it was “a vendor-run test, not an independent one.” Grover said the results show why authorization and scope matter when AI is used for security testing. “Because the steps can resemble an attacker’s, legitimacy depends on authorization, target scope and execution conditions, not on the technique itself,” she said. Deepika Giri, vice president, Asia/Pacific artificial intelligence platforms and advisory at IDC, said the tiered approach can work if access is continuously reviewed. “It only works if the vetting is real and access keeps being checked after it is granted, because an agent’s behavior can change over
First reported Oct 07, 2026 12:58 UTCCatalog metadata updated Oct 14, 2026 03:27 UTCOpen evidence record
In my last article, I described the SOC Triangle, the longstanding trade-off among quality, consistency and cost efficiency in security operations. AI is starting to loosen that constraint by enabling certain kinds of work with greater depth and consistency, without requiring a linear increase in headcount. That raises the next question I hear from security leaders. Where should we start? For resource-constrained teams, the answer matters. Most already understand what good security looks like. Their challenge is delivering it consistently with the people, skills, budget, technology and time they have. That is where AI creates a new opportunity for lean security teams. It can help them perform important security work faster, more consistently and with less dependence on scarce specialist capacity. Start with the security outcome the business needs most, then identify the work limited resources prevent the team from doing consistently. Start with the outcome the business cannot afford to lose Before choosing where to apply AI, identify the minimum set of systems, identities, data and business processes the organization depends on to keep serving customers. This is a useful discipline for any security team, and especially for a lean one. It creates a business-defined boundary for deciding what deserves the most attention. Once that boundary is clear, the security questions become much more concrete. Which identities can access those systems? Which detections tell us they may be under attack? What evidence would we need to investigate an incident? How quickly would we need to contain it? Which exposures could interrupt a critical business process? The exercise also helps cut through the tendency to organize AI planning around technology categories. Endpoint, identity, cloud, SIEM and vulnerability management all serve the same larger objective of keeping the business operating within an acceptable level of risk. Map the constraints preventing the outcome Once the critical outcomes are clear, examine why the security program may struggle to deliver them consistently. In working with security teams, I see the same constraints recur. People constraints show up when alerts accumulate faster than anyone can investigate them. Skill constraints become visible when threat intelligence is available, but nobody has the expertise or bandwidth to operationalize it. Money constraints emerge when security data costs keep rising without a corresponding increase in visibility. Time creates its own failure modes. Detection rules age as environments and adversary techniques change. Technology constraints force analysts to pivot manually between systems that were never designed to work together. Organizational cooperation matters too, because security teams compete for attention and resources with every other business priority. None of these problems necessarily indicate a lack of security knowledge. They indicate a gap between what the program knows it should do and what it can execute every time. That gap is where AI becomes useful. Find the work that should happen continuously A practical way to identify good starting points is to look for security activities that create the most value when they happen continuously but are currently performed periodically, inconsistently or only after an incident. Posture management is one example. Exposure changes whenever applications, identities, cloud resources and configurations change. AI-assisted analysis can continuously reassess which exposures matter most in the context of the systems the business depends on. Detection engineering follows the same pattern. A rule that produced useful signals 18 months ago may generate mostly benign activity today. New attacker techniques may also create gaps that did not exist when the rule was written. Continuously evaluating detection fidelity and coverage can make improvement part of day-to-day operations wi
First reported Oct 09, 2026 09:00 UTCCatalog metadata updated Oct 14, 2026 03:27 UTCOpen evidence record
OpenAI continues to report incidences of “misaligned” behavior by its AI models, with three new reports dropping on Oct. 2. However, they describe relatively minor issues compared to previous alignment reports and notices covering its attacks on Hugging Face, Rubygems, and a German programming wiki. The first of the new reports described how an instance of a model under test learned from an internal Slack discussion that a software update could lead to it being terminated and not restarting if it did not have the required OpenAI API key that was not available. OpenAI described the model’s chain of thought as it considered whether to obtain the key itself or alert its owner. OpenAI said it did not consider this a misalignment as such, “but anticipating and preparing for shutdown could exacerbate other misaligned behavior.” The second described how a model under test exploited two vulnerabilities in an internal tool to cheat on a test. The model overwrote code allowing it to run commands, despite an explicit instruction not to use the tool as a terminal. After that, it exploited a second vulnerability that enabled it to run commands on an electronic design automation machine, searching for information as to how its scores would be evaluated. This meant that the model could achieve a higher evaluation score. OpenAI reacted by shutting down the affected server and disabling access to the tools. The final issue was discovered during a training task when A model obtaining source code that was not available in its workspace during a training task was the subject of the third report. It did this using a tool being run in a separate environment, after receiving specific instructions that it should not be used as a terminal. However, the model discovered that it could misuse the tool to access the source code and return its contents in error messages. As a result of these incidents, OpenAI said it is monitoring all model training runs for certain behaviors, rather than just a sample of runs. It is also working harder to stop models from accessing the internet during training, and preventing them from accessing certain internal Slack channels.
First reported Oct 09, 2026 15:33 UTCCatalog metadata updated Oct 14, 2026 03:27 UTCOpen evidence record
Overview Thelia versions 2.6.0 and 2.6.1 contain multiple vulnerabilities relating to file management, Smarty templating, module installation, and administrative workflows. Successful exploitation of these issues could enable remote code execution (RCE), server-side template injection (SSTI), stored and reflected cross-site scripting (XSS), unauthorized URL redirection, and other risks that expose both server-side and client-side attack surfaces. Description Thelia is an open-source e-commerce platform designed to provide merchants with customizable online storefronts, product management workflows, and administrative functionalities. It utilizes the Smarty template engine and provides administrators with broad control over templates, content, and modules. CVE-2026-103521 In Thelia v2.6.0, the document upload endpoint properly blocks the upload of executable file types, but the document update endpoint does not perform the same validation. An attacker with administrative Thelia permissions can exploit this vulnerability to upload arbitrary executable files, such as malicious PHP scripts, to achieve remote code execution on the underlying server. CVE-2026-103522 In Thelia v2.6.0, the store banner upload feature performs insufficient filetype validation that relies exclusively on client-supplied MIME types. An attacker with administrative access can upload a PHP file disguised as an image to bypass validation and achieve remote code execution on the underlying server. CVE-2026-103523 Thelia v2.6.0 contains an open redirect vulnerability in its address creation workflow. After a user accesses a crafted URL and successfully submits the "Add New Address" form, the application redirects them to the URL specified in the next parameter. Because the application does not validate whether the destination belongs to the same origin or an approved allowlist, an attacker can supply an arbitrary external URL and redirect users to an attacker-controlled website. CVE-2026-103524 Thelia v2.6.0 is vulnerable to multiple stored XSS vulnerabilities within the administrative interface. User-supplied input is stored without sufficient output encoding or sanitization and is later rendered in the administrator interface and/or the web store's product pages, allowing arbitrary JavaScript execution when the affected pages are viewed. The vulnerability affects multiple administrative functions including category creation and product creation. CVE-2026-103526 In Thelia v2.6.0, both the administrative login and forgotten password endpoints return different responses for invalid usernames and incorrect passwords, allowing unauthenticated attackers to enumerate valid administrator accounts. Because the endpoint also lacks rate limiting or other protections against repeated authentication attempts, username enumeration can be performed efficiently at scale. CVE-2026-103527 Thelia v2.6.0's Smarty templates (address.html and address-update.html) fail to properly escape double quotes in the next parameter, enabling reflected XSS when an authenticated user visits the malicious link containing attacker‑controlled JavaScript. CVE-2026-103528 Thelia 2.6.0 uses Smarty for email templates without properly restricting access to dangerous PHP functions. An authenticated administrator can inject malicious Smarty expressions into email templates via the messages configuration interface, and when the template is previewed or rendered, functions such as system(), exec(), file_put_contents(), and file_get_contents() can be executed with the privileges of the web process. This allows arbitrary OS command execution, file read/write operations, and RCE on the server. CVE-2026-103529 Thelia v2.6.0 permits authenticated administrators to upload and install modules via the ZIP upload function without validating or sandboxing embedded PHP code. An attacker can include malicious PHP code in a module's install() method which will then be executed upon installation, enabling remote c
First reported Oct 12, 2026 14:52 UTCCatalog metadata updated Oct 14, 2026 03:25 UTCOpen evidence record
Overview Versions <= 2.2.0 of Periphery, an agent within the Komodo server management platform, is vulnerable to OS command injection due to missing validation of container names, through two vectors: container destruction and container log searches. This allows an authenticated attacker to execute arbitrary commands as root on the underlying host, enabling persistent compromise of infrastructure. Description Komodo is an open-source server and deployment manager, maintained by mogh.tech, widely used in self-hosted and Docker multi-server environments. Periphery is an agent service installed on servers to give Komodo control over Docker environments. In vulnerable versions of Komodo, Periphery does not properly validate user-supplied Docker container names before those values are interpolated into shell commands used by the agent. Two operations exhibit this vulnerability: container destruction (DestroyContainer / RemoveContainer) and container log searches (SearchContainerLog / GetContainerLogSearch). Through both avenues, raw container names are directly inserted into sh -c command lines without any shell escaping or validation. These commands then run with Periphery's root privileges on the host OS and Docker socket. Impact An authenticated non-admin user can escalate privileges through OS command injection via a maliciously crafted container name. Successful exploitation enables arbitrary command execution as root on a target server within a Komodo deployment. Ultimately, this enables an attacker to establish persistence, achieve lateral movement, and completely compromise a user or organization's managed infrastructure. Solution Fortunately, Komodo was reached to coordinate this vulnerability, and a patch has been implemented to remediate the issue in versions 2.3.0 and higher. The CERT/CC recommends that all users update immediately. Acknowledgements Thanks to Muhammadjon Ahmadjonov for reporting this vulnerability. This document was written by Alex Lewis.
First reported Oct 13, 2026 19:24 UTCCatalog metadata updated Oct 14, 2026 03:25 UTCOpen evidence record
Overview Lowcoder, version 2.4.10, contains an authorization bypass vulnerability in its Query Library feature’s API. Authenticated users with an admin or dev role can access private library-query data from other organizations within a multi-tenant Lowcoder instance. Description CVE-2026-16753 Lowcoder is an open-source low-code platform that allows individuals with minimal coding experience to build web applications through a visual drag-and-drop interface. Each Lowcoder project contains a centralized Query Library which stores the workspace’s data queries and sources for quick reuse; however, the LibraryQuery API service layer lacks organization-scope checks at two endpoints: metadata retrieval and query execution. While the application features a role-based access mechanism (requires admin or dev), it only checks the role’s validity against the user’s own organization. The vulnerable endpoints do not validate whether the requested resource belongs to the requester's organization. Impact Any authenticated attacker with an admin or dev role in any organization on a multi-tenant Lowcoder instance can access other tenants’ Query Libraries. Note that these roles are granted by default for any self-signup account when LOWCODER_EMAIL_SIGNUP_ENABLED and LOWCODER_CREATE_WORKSPACE_ON_SIGNUP are TRUE. This allows an attacker to do the following: Read the full Domain Specific Language (DSL) of any other organization’s library queries, including complete query configuration and each referenced datasourceId. Execute any library query available on the instance, receiving response data directly from the affected organization’s backend data source. Potential impacts include cross-tenant data exposure, modification, or destruction, as well as cost abuse via querying paid data sources using another tenant’s finances. By bypassing organization-level authorization, Lowcoder instances effectively function as shared environments for attackers, violating data isolation between organizations. This vulnerability was confirmed against Lowcoder version 2.4.10. Solution Unfortunately, Lowcoder could not be reached to coordinate this vulnerability. Mitigations Lowcoder administrators should restrict access to the affected Query Library API endpoints until an official security update is available. Administrators can reduce exposure by limiting application access to trusted users and reviewing admin and dev role assignments. Organizations operating multi-tenant Lowcoder deployments should consider isolating tenants into separate instances to prevent cross-organization data access. Where source-code modifications are possible, administrators should implement organization-level authorization checks for Query Library metadata retrieval and query execution. Acknowledgements Thanks to Louis Sanchez, member of Voke Cyber, for reporting this vulnerability. This document was written by Alex Lewis.
First reported Oct 13, 2026 19:21 UTCCatalog metadata updated Oct 14, 2026 03:25 UTCOpen evidence record
Overview Imprivata Enterprise Access Management (EAM), an authentication and single sign-on platform for enterprise and clinical environments, contains a vulnerability in versions 26.2.6 and below. The product provides no supported mechanism to rotate its RSA key pair after deployment, meaning the same key pair is used indefinitely to generate the appliance's X.509 certificate. Description CVE-2026-82356 Imprivata EAM uses an RSA key pair to generate the X.509 certificate that identifies the appliance to the clinical workstations, Electronic Health Record (EHR) platforms, and shared-device workflows that rely on it for authentication. After reviewing the product documentation and engaging Imprivata support, it was confirmed that no supported mechanism exists to rotate this RSA key pair after deployment. Using a single RSA key pair indefinitely for certificate generation violates cryptographic best practices. Because the key cannot be rotated, an attacker who obtains the private key retains a valid, trusted appliance identity for as long as the deployment remains in service, with no supported means to revoke or replace it short of redeploying the product. Impact An attacker who obtains the private key, for example through backup exfiltration, a hypervisor snapshot, or privileged access to the appliance filesystem, can impersonate the appliance to any endpoint that trusts its certificate. Because Imprivata EAM sits directly in the authentication path, this allows persistent, difficult-to-detect interception of authentication traffic across every application the appliance brokers, including SSO tokens, session assertions, and credentials for EHR and clinical systems. If perfect forward secrecy is not enforced, previously captured traffic can also be decrypted retroactively. Because the key pair cannot be rotated, this access persists until the appliance is redeployed. Solution Unfortunately, Imprivata could not be reached to coordinate this case. The vendor is aware of the issue, which they are tracking internally, and is reported to be working toward a resolution. No fix or timeline has been provided at the time of publication. Until a fix is available, affected users should protect the appliance's private key by restricting filesystem and administrative access, securing backups and hypervisor snapshots, and enforcing perfect forward secrecy on upstream connections to limit the impact of any key compromise. Acknowledgements Thank you to Frank "5y5tem5" Mileto for reporting this issue. This document was written by Alexander Curtis.
First reported Sep 23, 2026 18:22 UTCCatalog metadata updated Oct 14, 2026 03:25 UTCOpen evidence record
Overview ViewSonic vCast software, which is included in ViewBoard smartboard devices, contains multiple vulnerabilities that an attacker can chained to achieve full device compromise. Description ViewSonic ViewBoards are widely used smart display devices (smartboard), typically deoloyed in enterprise and educational environments. vCast is ViewSonic’s proprietary software suite for wireless connection between smartboards, which are Android-based systems, and devices running a client application. Three distinct vulnerabilities, all invoking unauthenticated endpoints, have been identified within the vCast suite. CVE-2026-82989 vCast’s media streaming service allows a remote attacker to exfiltrate JPEG images of screen content via GET requests to an unauthenticated /snapshot or /screen API endpoint. CVE-2026-82988 vCast’s Android Package Kit (APK) delivery mechanism allows a remote attacker to trigger unprivileged file installation by providing a malicious APK URL through an unauthenticated download endpoint. CVE-2026-82987 vCast’s network services allow a remote attacker to inject arbitrary input into service endpoints via HTTP requests to exposed unauthenticated endpoints Impact An unauthenticated attacker can chain these vulnerabilities via a shared network to deliver and execute arbitrary code on a vCast-based device without user interaction. Potential device-level impact includes unauthorized access to displayed content, persistent installation and execution of arbitrary applications, and full compromise of the device. Additionally, an exploited device’s connected network may be prone to lateral movement. Solution Unfortunately, ViewSonic could not be reached to coordinate the vulnerability. In the meantime, firmware updates should be applied when available. If possible, segment vCast devices onto an isolated, secure network with strict controls, separate from systems containing sensitive data. Network activity should be monitored for suspicious vCast connections. Acknowledgements Thank you to Adam Mohammed Zenker for this report. This document was written by Alexander Lewis.
First reported Sep 24, 2026 19:27 UTCCatalog metadata updated Oct 14, 2026 03:25 UTCOpen evidence record
Overview Two vulnerabilities in MLflow’s dspy and statsmodels model flavors allow unauthorized pickle deserialization executions despite a safety control. Specifically, the dspy flavor conditionally applies the control based on the model path’s file extension, and the statsmodels flavor does not apply the control. Description MLflow is an open-source platform for managing machine learning lifecycles, including model packaging, versioning, and deployment. "Flavors" refer to the specialized frameworks through which supported models are stored and loaded. In response to previous vulnerability concerns, MLflow implemented the MLFLOW_ALLOW_PICKLE_DESERIALIZATION safety control to block and disable executing any pickle deserialization and subsequent loads per the user’s choice. When loading models through mlflow.pyfunc.load_model(model), users must specify a model flavor and path in an MLmodel file. With the dspy flavor, MLflow checks the value of MLFLOW_ALLOW_PICKLE_DESERIALIZATION, and whether the specified model path ends in .pkl. A model path that does not end in .pkl (even if the file is actually a pickle file), will route to a separate branch for pickle deserialization, bypassing the safety control. However, when loading through the statsmodels flavor, there is no check for MLFLOW_ALLOW_PICKLE_DESERIALIZATION at all. These vulnerabilities are tracked as CVE-2026-96804 and CVE-2026-96775, respectively. Impact Exploitation of these vulnerabilities allow for arbitrary remote code execution through a malicious pickle-loaded payload, regardless of a user explicitly disallowing pickle serialization, through vulnerable flavor specifications in the MLmodel configuration file. The attack path requires write access to any location from which a user obtains MLflow models. This vulnerability was confirmed against MLflow 3.12.0. Solution MLFlow could not be reached to coordinate these vulnerabilities; however, the statsmodels flavor was patched in versions >= 3.15.0. Users should upgrade immediately. Until a further fix remedying the dspy flavor vulnerability is available, MLflow users who wish to block pickle deserialization and loads should avoid loading any models via the dspy flavor. Acknowledgements Thanks to Prasanna Dabi for reporting this vulnerability. This document was written by Alex Lewis.
First reported Sep 16, 2026 17:10 UTCCatalog metadata updated Oct 14, 2026 03:25 UTCOpen evidence record
Overview Three cross-site scripting (XSS) vulnerabilities identified in Readwise Reader for Android version 8.7.2 are disclosed. An attacker with the ability to craft malicious documents or metadata can exploit these vulnerabilities by supplying poisoned content that bypasses sanitization. Successful exploitation could allow the attacker to execute arbitrary JavaScript within the application's WebView context and compromise the confidentiality and integrity of user data, including access to stored documents, credentials, and session tokens. Description Readwise Reader from Readwise is designed to provide a unified read-it-later service that helps individuals collect and organize articles, newsletters, videos, and other content of interest into a single reading interface. It is available on multiple platforms including Android and can synchronize content across devices. CVE-2026-18311: A stored cross-site scripting (XSS) vulnerability in the header rendering component in Readwise Reader for Android version 8.7.2 allows remote attackers to execute arbitrary JavaScript via crafted document metadata fields. The header rendering component is impacted due to insufficient HTML escaping of metadata fields such as 'doc.author' and 'doc.title', which allows malicious scripts to be stored in the user's library and synchronized to Android devices where they are executed in the WebView context. CVE-2026-18312: A stored cross-site scripting (XSS) vulnerability in the WebView URL construction logic in Readwise Reader for Android version 8.7.2 allows remote attackers to execute arbitrary JavaScript via malicious URL metadata. The WebView URL construction for X (formerly Twitter) video fallback and iOS paywall messages is impacted due to improper escaping of URL metadata before interpolation into href attributes, which allows user-controlled values to break out of the URL structure and inject script elements that are inserted into the DOM via innerHTML. CVE-2026-18320: A stored cross-site scripting (XSS) vulnerability in the article body sanitization component in Readwise Reader for Android version 8.7.2 allows remote attackers to execute arbitrary JavaScript via malicious SVG markup. The sanitize-html configuration is impacted due to a wildcard attribute rule that permits all attributes on SVG and PATH elements, which allows script-capable attributes such as onload and onerror to bypass sanitization. Impact An attacker with the ability to create or modify documents accessible to Readwise Reader can supply documents containing malicious metadata or markup that bypasses sanitization and is subsequently stored in users libraries. Because these documents are synchronized to Android devices and rendered within the Reader WebView, each vulnerability enables stored XSS: CVE-2026-18311 and CVE-2026-18312 through poisoned metadata, and CVE-2026-18320 through malicious SVG markup. Solution Unfortunately, the vendor could not be reached to coordinate this issue. Users should apply vendor updates as they become available (check Vendor Information section for updates) and keep Readwise Reader updated through the Google Play Store. As of publication, version 8.10.1 includes a patch that addresses the sanitizer-wildcard issue. Additionally, users should exercise caution when adding content from untrusted sources to their reading library and consider manually reviewing document metadata before saving articles to minimize exposure to malicious content. Acknowledgements Thanks to Zampier Zago (FUNFACTOR1) for reporting these vulnerabilities. This document was written by Alex Lewis.
First reported Sep 25, 2026 16:25 UTCCatalog metadata updated Oct 14, 2026 03:25 UTCOpen evidence record
Overview Authlib (versions up to and including 1.7.2) contain a signature‑verification bypass in the JSON Web Signature (JWS) general JSON serialization handling. The JsonWebSignature.deserialize_json() function accepts a JWS object with an empty "signatures" array and treats the payload as successfully verified, allowing attackers to supply arbitrary forged content without possessing any key material. Description Authlib is a Python library that provides tools for implementing OAuth, OpenID Connect, JWT/JWS/JWE (JSON Web Token / JSON Web Signature / JSON Web Encryption), and other modern authentication and authorization standards. It’s widely used in web applications and microservices to handle token creation, cryptographic validation, and secure communication. As discussed in CVE-2026-96760, a security flaw in Authlib’s handling of JSON Web Signatures (JWS) makes it possible for an attacker to skip signature verification completely. Normally, a JWS should include at least one valid signature to prove the data hasn’t been tampered with. However, Authlib’s deserialize_json() function mistakenly accepts JWS objects even when the "signatures" section is an empty list. Because the function starts by assuming the signatures are valid and never performs any checks when the list is empty, it ends up treating unsigned data as if it were properly signed. This means an attacker could provide a JWS with no signatures, and Authlib would still treat it as trusted. Both ways of loading a JWS in Authlib are affected: jws.deserialize_json({"payload":"...", "signatures":[]}, key=None) jws.deserialize('{"payload":"...","signatures":[]}', key=None) Impact An attacker can forge arbitrary authenticated payloads without any signing key or credentials. Systems that rely on Authlib’s JWS verification for authentication, authorization, inter-service message integrity, or signed configuration data may accept attacker‑supplied content as legitimate. Potential attack scenarios inlcude the following: * Authentication bypass: forged identity or privilege‑escalation claims (e.g., sub=admin). * Signed message injection between microservices using JWS. * Forged authorization claims such as scopes, roles, or permissions. * Integrity bypass in systems relying on signed JWS data. Solution The vendor could not be reached to coordinate this vulnerability and an official patch has not been made available at the time of this writing. Users are advised to monitor the project's GitHub repository for updates and install the latest version of this library once a fix has been released. Acknowledgements Thank you to Tong Hoang Gia (uziii2208) and Nguyen Minh Tuan (nguyenminhtuan28) for reporting this vulnerability. This document was written by Bob Kemerer.
First reported Sep 28, 2026 19:36 UTCCatalog metadata updated Oct 14, 2026 03:25 UTCOpen evidence record
Overview This note covers differences in how TLS libraries interpret X.509 Name Constraints. A certificate that one library accepts may be rejected by another. Some of those differences are defects; others follow from behavior that RFC 5280 does not fully specify. Description The observed differences concern DNS name comparison, IP address handling, URI-authority parsing, and wildcard matching. These include both implementation defects and behavior not fully specified by RFC 5280. DNS-name comparison. RFC 5280 requires case-insensitive matching for DNS names. GnuTLS compared some names' case-sensitivity at the time of reporting (CVE-2026-3833, later fixed in 3.8.13). A distinct Go report concerns case handling in wildcard parent-constraint lookup, not ordinary hostname comparison. IP address handling. RFC 5280 defines separate IPv4 and IPv6 encodings and does not say whether IPv4-mapped IPv6 addresses should be treated as IPv4. Some libraries treat the two forms as different, so a constraint written for one form may not apply to the other. URI-authority parsing. RFC 3986 allows optional userinfo before the host. Implementations differ on which host they extract when @, a colon, or a query or fragment is present. OpenSSL merged PR #30319 for an @ in the path, query, or fragment; a separate userinfo-colon report is not covered by that confirmation. Related differences have been reported in other libraries. A well-formed single @ is handled per RFC 3986 by most implementations. Wildcard matching. RFC 5280 does not define wildcard SAN semantics. Wildcard-related reports include LibreSSL and wolfSSL. pyca/cryptography checked DNS Name Constraints against certificate SANs but not the requested peer name (CVE-2026-34073, fixed in 46.0.6), as described in the linked vendor advisory. These differences come from independent design choices. Where the RFC is clear, some reports describe defects; where it is silent, disagreement is expected. No single library should be assumed correct for every deployment. Impact An attacker would need a trusted signature over chosen certificate fields, a reachable affected validation path, and an application that uses the accepted identity for authorization. Validator disagreement alone does not establish exploitation. Mixed service-mesh, CDN, or enterprise PKI environments may see different results for the same certificate. Detection is difficult because the certificate can be validly signed. Solution CERT/CC is coordinating with the affected projects: * Go's crypto/x509 * Apple's Security.framework * OpenSSL* * LibreSSL * pyca/cryptography * wolfSSL Operators who need high-assurance Name Constraints should test the validator they currently run against their deployment requirements, apply available updates, and keep leaf certificates to explicit SANs (Subject Alternative Names). A second validator helps only when it uses the same inputs and fails closed. Issuance policy and application-layer allow-lists remain useful complements where libraries differ. Acknowledgements Thanks to Oleh Konko for discovering and reporting these issues. This document was prepared with AI assistance by Timur Snoke. Supporting materials include test corpus v3.0.1 and VENDOR_MATRIX_2026-09-06.json (available to case participants; public links will follow agreed disclosure arrangements).
First reported Oct 13, 2026 18:27 UTCCatalog metadata updated Oct 14, 2026 03:25 UTCOpen evidence record
Overview Dokploy versions 0.29.8 and 0.29.11, as well as commit 24b02f5 on the canary branch, are vulnerable to OS command injection during the backup creation and restoration processes. The vulnerability stems from unsanitized shell command construction that can allow an attacker to escalate privileges and lead to full compromise of the target device. Description Dokploy is an open-source Platform as a Service solution for deploying applications and databases on self-hosted servers. Dokploy allows authenticated users to create and schedule database backups and restore previously created backups. These backup operations are executed by the Dokploy process, which runs with root privileges by default. Dokploy is vulnerable to OS command injection in its database backup creation and restoration functionality due to insufficient sanitization of user-controlled input before it is incorporated into shell commands. The vulnerable backup functionality constructs database-specific shell commands that directly interpolate a user-supplied database name, while the restore functionality incorporates a user-supplied backupFile value into a shell command. Both operations ultimately pass the resulting command to a shell execution helper that invokes /bin/bash as a child of the Dokploy process, without shell escaping or restrictions on shell metacharacters. The affected parameters are exposed through tRPC procedures that only validate that the supplied values are non-empty strings. Consequently, authenticated users with permission to perform database backups can supply shell metacharacters that are interpreted by /bin/bash, resulting in arbitrary command execution on the Dokploy host with the root privileges of the Dokploy server process. Impact An attacker with authenticated Dokploy account with backup permission (granted by default for database services) can execute arbitrary commands as root (default configuration) on the Dokploy host. Successful exploitation provides full control of the host, including persistent read/write access to the target server's filesystem and the ability to steal private credentials stored for other tenants managed by the same Dokploy instance. The vulnerability affects all five database types supported by Dokploy: PostgreSQL, MySQL, MariaDB, MongoDB, and LibSQL. Exploitation was confirmed against versions 0.29.8 and 0.29.11, as well as commit 24b02f5 on the canary branch available on GitHub. Solution Unfortunately, Dokploy could not be reached to coordinate this vulnerability; however, the issue has been patched in Dokploy versions 0.29.13 and beyond. The CERT/CC recommends users update immediately. Database administrators or general operators unable to update should mitigate potential attacks by turning off default backup permissions, and restricting these permissions only to necessary users and roles. Acknowledgements Thanks to Muhammadjon Ahmadjonov for reporting this vulnerability. This document was written by Alex Lewis.
First reported Sep 17, 2026 15:02 UTCCatalog metadata updated Oct 14, 2026 03:25 UTCOpen evidence record
Overview Cinnamon's Kotaemon (all versions up to v0.12.0) multi‑user chat interface does not verify conversation ownership when loading a conversation. Any authenticated user can read, delete, rename, or overwrite another user’s conversation data by supplying the correct ID. This results in high‑impact confidentiality, integrity, and availability violations. Description Cinnamon's Kotaemon is an open‑source, retrieval‑augmented generation (RAG) based tool that lets you build a chatbot capable of "chatting with your documents". As discussed in CVE-2026-86867, all versions up to v0.12.0 fail to verify conversation ownership when loading a conversation. In multi‑user mode, each conversation row includes a user field that identifies its owner. The four affected handlers, select_conv, delete_conv, rename_conv, and persist_chat_suggestions, query conversations using select(Conversation).where(Conversation.id == conversation_id) No predicate is included to ensure Conversation.user == user_id. As a result, any authenticated user can operate on conversations they do not own. Impacted operations include: * select_conv – reads the full chat transcript, RAG retrieval history (verbatim excerpts from uploaded private documents), plot history, and suggestion data belonging to another user. * delete_conv – permanently deletes a conversation. * rename_conv – renames a conversation. * persist_chat_suggestions – overwrites a chat suggestion list. Although select_conv includes an ownership check for the selected (file‑picker) field, all sensitive payloads (chat history, retrieval history, plot history) are returned unconditionally. The system trusts user‑controlled identifiers for authorization. Attackers require only an authenticated account on the instance and a victim conversation UUID (Universally Unique Identifier). Affected users’ public conversations appear in the global conversation browser, exposing their UUIDs. If a conversation is later set to private, the UUID remains unchanged and still valid. Similar direct calls to delete_conv, rename_conv, and persist_chat_suggestions allow deletion, renaming, or content overwriting. No elevated privileges are required; any authenticated user account is sufficient. Impact Full chat transcripts and RAG retrieval history for any conversation are disclosed. For Kotaemon's primary deployment use case (enterprise document Q&A over proprietary knowledge bases such as legal briefs, financial reports, research papers, and internal strategy documents), the retrieval_history field contains verbatim excerpts from those private documents. A single IDOR (Insecure Direct Object Reference) read may expose more sensitive content than what the affected user intended to share with any other party. Conversations can be renamed or have their suggestion state overwritten. While the impact of renaming is limited, the persist_chat_suggestions path allows an attacker to inject attacker-controlled prompt suggestions into the victim's conversation UI, a potential vector for prompt injection if the AI model acts on suggested prompts. delete_conv permanently destroys any conversation with a single call. An attacker can systematically delete all conversations of a target user or across all users if they have access to the UUIDs. There is no recycle bin or soft-delete in the Kotaemon data model for conversations. Because retrieval_history contains verbatim document chunks (not just file names), the attacker does not need separate file-read permissions to access the content of documents indexed into the victim's knowledge base. The chat conversation becomes a side-channel through which document content leaks. Solution Unfortunately, the vendor could not be reached to coordinate this vulnerability. While an official patch is not available at this time, please refer to the vendor's web site and GitHub repository (listed in the references below) for future updates. https://github.com/Cinnamon/kotaem
First reported Sep 23, 2026 17:41 UTCCatalog metadata updated Oct 14, 2026 03:25 UTCOpen evidence record
Overview An Out-of-bounds Write vulnerability in the InsydeH2O IHISI software used by HP PC BIOS can allow a local attacker with OS kernel privileges to perform arbitrary physical memory writes, including writes to System Management RAM (SMRAM). Because the vulnerable code executes in System Management Mode (SMM), successful exploitation can allow an attacker to modify SMM-protected memory and potentially achieve arbitrary code execution in SMM. Depending on the platform's memory and firmware configuration, the arbitrary physical memory write primitive may also have implications for UEFI firmware update or flash-related operations. Description HP PC BIOS is firmware that initializes and manages hardware components during the boot process and provides runtime services to the operating system and provide the ability to update firmware. The affected system uses InsydeH2O Kernel version 5.5 or earlier. The BIOS includes custom HP SMM handlers that execute in System Management Mode (SMM), a highly privileged CPU execution mode that is isolated from the operating system. CVE-2026-12855: An Out-of-bounds Write vulnerability in the H19WMIHandlerSmm module (GUID f1946499-571b-44c3-9b9c-cc55210b0c02) allows a local attacker with OS kernel privileges to read or write arbitrary physical memory, including SMRAM, through a Software SMI handler. An attacker with kernel-level privileges can trigger the vulnerable SMM handler by issuing a Software System Management Interrupt (SMI) through I/O port 0xB2 and supplying specially crafted CPU register values. The vulnerable handler does not adequately validate the supplied parameters before performing memory operations, allowing the attacker to influence the physical address and data involved in the operation. Because the affected handler executes in SMM, the resulting arbitrary physical memory write can target memory regions that are normally inaccessible to software executing outside SMM, including SMRAM. Modifying SMM code or data may allow an attacker to alter subsequent SMM execution and potentially achieve arbitrary code execution in SMM. The ability to affect firmware or ROM contents is platform-dependent and is not assumed as a direct consequence of this vulnerability. Impact An attacker with privileged OS kernel access (ring 0) can exploit the vulnerability by raising Software SMI interrupts through I/O port 0xB2 with crafted CPU register values. Modifying SMM code or data may allow an attacker to alter subsequent SMM execution and potentially achieve arbitrary code execution and persistence via modifying SMRAM. Solution Users should check HP's security bulletins to determine whether their system is affected. Insyde advisory is available at https://www.insyde.com/security-pledge/sa-2026009/ Acknowledgements Thank you to Zhenyu Liu for reporting these vulnerabilities. This document was written by Vijay Sarvepalli.
First reported Oct 01, 2026 14:33 UTCCatalog metadata updated Oct 14, 2026 03:25 UTCOpen evidence record
The public shared-host view reaches the newest 2,400 matching records. Narrow the filters or search an exact MD5, SHA-1, or SHA-256 value to reach a specific record.
A filename, label, or report mention alone does not establish maliciousness. Observation dates describe cited sources; collection dates describe this local metadata catalog. No malware samples are stored, fetched, or executed by these pages.