component

Introduction Back in October 2022, Kaspersky GReAT was looking into a peculiar advertisement on a hacking forum. A cybercriminal had been advertising a UEFI bootkit, dubbed BlackLotus, that could bypass Secure Boot, for $5,000. Given the low price for such powerful capabilities, the cybersecurity community initially took this advertisement with a grain of salt. As no BlackLotus samples were found in the wild, no one could at the time verify the claims made in the forum post. BlackLotus advertisement However, about half a year later, in March 2023, ESET confirmed that the BlackLotus advertisement was genuine. The researchers tracked down samples of this bootkit and confirmed that it can indeed bypass Secure Boot through a vulnerability called Baton Drop (CVE-2022-21894). As this vulnerability was still exploitable in 2023, Microsoft had to release multiple security updates to address it. Since the release of these updates, the BlackLotus bootkit has gone quiet — no publicly known attacks have used it. Yet in early 2026, we discovered a malware sample similar to BlackLotus that was used in an APT campaign in Central Asia. In this report, we share our findings, including new payloads and possible attribution of this campaign. The return of the infamous bootkit In early 2026 we identified a complex APT attack targeting diplomatic agencies in Central Asian countries — namely Tajikistan, Uzbekistan, and Turkmenistan. This attack involved a UEFI bootkit that we dubbed BlackX. Having examined it, we found it to be similar to BlackLotus. Attackers have been deploying BlackX after compromising the victim machine networks and obtaining administrator privileges. To install the bootkit, we observed them dropping the following files: inst.exe , an installer executable PVMDIJGKAX2 , an RC4-encrypted extensionless file containing files and strings required for the installation The installer was launched with the command line C:\ProgramData\Intel\inst.exe PVMDIJGKAX2 Q46F6MDLI3RX2KV1 . The last argument here is the RC4 key used for decryption. Curiously, the file inst.exe does not contain any malicious strings or embedded blobs. All the files needed to install the malicious payload are inside PVMDIJGKAX2 , which makes it harder for incident responders to retrieve the bootkit components. The installer package drops a set of files to both system and UEFI partitions, designed to exploit the Baton Drop vulnerability. We noted that the implementation of the exploit is remarkably similar to the one used in the BlackLotus malware. As with BlackLotus, the goal of the exploit is to install custom Machine Owner Keys (MOK), which allows loading arbitrary EFI files on the target machines to manipulate Secure Boot. While the vulnerability exploitation chain was implemented very similarly to BlackLotus, we spotted differences between the exploits in BlackLotus and BlackX. That said, the source code of the BlackLotus bootkit has never been published online. This could mean that the attackers behind BlackX either reverse-engineered the BlackLotus bootkit or purchased its source code from cybercriminals. Either way, this is an interesting observation, as we rarely see APT actors borrow ideas or code from cybercrime actors. Payload launched by the bootkit The UEFI payload delivered during the Baton Drop exploitation has a classic bootkit goal — to inject a malicious driver into the Windows kernel. This driver differs from the one deployed by BlackLotus and is signed with a certificate belonging to an organization named 温江区明宇网络技术服务工作室 (English: Wenjiang District Mingyu Network Technology Service Studio). At the time of writing, this certificate (serial number: 0bcdf5e0da32d68900b8b7638459d072) has been revoked by its issuer. The driver aims to tamper with security solutions installed on the machine. For example, it disables process, thread, and registry callbacks related to security solutions. It also tampers with ETW providers so that security solutions cannot access their output. Curiously, some of the tampering procedures are designed to run only if Kaspersky or Avast solutions are installed on the infected machine. However, during dynamic analysis of this driver, we found that these procedures are useless — they fail to interfere with Kaspersky products in any way. The driver also protects the bootkit’s files from tampering. It intercepts kernel requests to open these files and returns a handle to calc.exe instead of a malicious file handle. User-mode second-stage payloads Apart from tampering with security solutions, the driver also deploys a user-mode payload. We observed two such payloads, used for cyberespionage, in the wild. One of them is a RAT that can load further-stage .NET payloads. This RAT uses cloud storage for C2 server communications — we observed its versions using Google Drive, OneDrive, and Yandex.Disk. Having connected to a cloud storage service, this RAT iterates over files available there and interprets them depending on the file suffix. Below is a list of supported suffixes: File suffix Description Type 0X01 A .NET file. The task is to parse it and run the method TEST.Class1.RunCMD(argument_array) from the module Input 0X02 Result of the call TEST.Class1.RunCMD(argument_array) Output 0X03 Task to upload a file to the drive Input 0X04 Uploaded file Output 0X05 Task to download a file to an infected machine Input 0X06 File download status Output SSSR Contains initial system info Output We also observed another payload delivered through the bootkit, which we dubbed OxiDLLRunner. It is a malicious DLL obfuscated with OLLVM. It is loaded by the legitimate file googleupdate.exe (original filename: jcef_helper.exe , MD5: AF8A983B9ADA07EAE1259BF2953ABD40), which is also delivered by the bootkit. The DLL decrypts the contents of the file v8_context_snapshot.bin , which resides in the same folder, and then jumps to the beginning of the decrypted content. The decrypted data starts with shellcode followed by a PE file, which is a Rust payload designed to communicate with the www[.]archivetj[.]com C2 server. During communication, this payload is supposed to receive DLL files exporting a function named create_plugin , which are then executed in separate threads. Attribution Based on the following facts, we have attributed this attack to the APT41 threat actor with medium confidence: In June 2026, ESET published a blog post on attacks by the FishMonger threat actor, which the community assumes to be related to APT41. This post describes a kernel implant with a PDB path starting with C:\Users\ xdd \Desktop. While describing the campaign, the post also suggests the possible use of an unspecified UEFI bootkit component, which might exploit CVE‑2023‑24932. We observed the identifier “xdd” used multiple times in the BlackX bootkit payloads, so we assess that BlackX is the UEFI bootkit referenced in the ESET blog post; The payloads deployed by BlackX are loaded using a legitimate executable abused via DLL sideloading, and an encrypted file — this pattern is common among Chinese-speaking threat actors; The OxiDLLRunner file has been obfuscated with OLLVM, an obfuscator commonly used by Chinese-speaking actors. Why did the target organizations get infected? During our initial analysis of BlackX, we thought that attackers succeeded in deploying it due to the negligence of the target organizations. Baton Drop, the vulnerability used to deploy BlackX, was disclosed back in 2023 and was patched, so we first thought that the infected machines lacked the relevant updates. However, our investigation proved this wrong — the targeted machines were fully patched. Instead, we found out that the problem was with the patch itself. As it turned out, the patch for the Baton Drop vulnerability is designed to revoke the “Windows Production PCA 2011” certificate used to sign vulnerable UEFI components. However, this revocation does not happen automatically upon patch installation — the user has to trigger it manually . This is done with the following steps: A registry flag is set inside HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot; A scheduled task named Secure-Boot-Update is created. This patch is designed to be applied manually — for instance, applying it automatically could break dual-boot systems relying on the “Windows Production PCA 2011” certificate to load. At the same time, this patch deployment practice creates a problem — as it is extremely unusual for a system administrator to take extra steps after installing an update. Usually, when applying patches, system administrators take no further action unless an installation failure occurs. These instructions for activating the patch are buried deep on the Microsoft website, and we assess that they are quite hard for an average IT administrator to notice. Curiously, Microsoft’s plan for deploying the Baton Drop patches mentions an “Enforcement Phase” that involves revoking the “Windows Production PCA 2011” certificate automatically, without user interaction. At the time of publishing this post, this stage has not been implemented. On October 19, 2026, this certificate expired, but this does not prevent the vulnerable binaries from loading unless the certificate is blocklisted. It is likely that the threat actor behind this campaign took into account that few organizations realized the importance of manually activating the Baton Drop patch. As such, we believe they decided to invest time in understanding how BlackLotus works and creating a copycat of this bootkit. Conclusion Patch management is important for every organization, as updates from vendors help protect software and hardware against known vulnerabilities. However, sometimes installed patches fail to protect against the flaws they address. The BlackLotus story we described is not the only such example — for instance, in 2025 Microsoft released an update against the ToolShell vulnerability that also had to be applied manually. However, modern security solutions are designed to account for such cases when installed patches fail to protect against security flaws for one reason or another. For instance, the Exploit Prevention component available in Kaspersky products prevents exploits from running if the patch is not applied, or if it is a zero-day vulnerability with no available patch. It is thus crucial to equip all machines in an organization with security solutions and constantly monitor the alerts they raise.

On October 21, 2026, the PHP project released emergency fixes for two critical remote code execution (RCE) vulnerabilities in the PHP core runtime, tracked as CVE-2026-109618 and CVE-2026-109619 and collectively named PHP2Shell. Both are rated 9.2 (Critical) under CVSS v4.0, and both allow an unauthenticated attacker to run code on a vulnerable server. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Patching is the only complete fix, and you should upgrade PHP as your first priority. But patching a fleet takes time: you need to inventory where PHP runs, schedule maintenance windows and test applications against the new builds. This post shows you how to use AWS Web Application Firewall ( AWS WAF ) to help reduce exposure to the confirmed attack paths during that window. You’ll learn which request patterns to block, how to write the rules in AWS WAFv2, how to deploy them without breaking legitimate traffic and where its protection ends, so you don’t develop a false sense of safety. For how Amazon threat intelligence detected PHP2Shell exploitation before public disclosure, see Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot . For AWS service status and the AWS WAF rule that AWS recommends, see AWS Security Bulletin 2026-143-AWS . IMPORTANT: Patching is the only complete fix, and you should upgrade PHP as your first priority. The vulnerabilities in brief Both PHP2Shell vulnerabilities are unauthenticated RCE issues rooted in how PHP handles multipart/form-data request processing (the request format browsers use for file uploads) before your application code runs, which is why the AWS WAF rules in this post focus on multipart traffic, request body size, and the session upload progress field. At a high level, CVE-2026-109618 corrupts memory when PHP runs out of memory mid-request, and CVE-2026-109619 lets one request leave behind stale data that a later request on the same worker process reuses. For the root-cause analysis, affected versions, and PHP’s own guidance, see the official PHP advisories and release announcement: CVE-2026-109618 (out-of-memory corruption) – PHP advisory GHSA-w8hw-w9fx-j79w CVE-2026-109619 (stale global state) – PHP advisory GHSA-6wmf-4rv5-p3rp PHP security release announcement, October 21, 2026 Where AWS WAF fits in your response AWS WAF is a defense-in-depth control in this situation, not a replacement for the PHP upgrade. The PHP advisories are explicit: updating to a patched release is the only complete mitigation. One of the two vulnerabilities is largely outside the reach of any web application firewall, as explained later. Treat the rules in this post as mitigating controls that help reduce exposure while you patch, then remove them or keep them as supporting controls after you’ve patched. AWS WAF inspects HTTP requests at the edge. It doesn’t parse the internal structure of a multipart body, and it has no visibility into PHP worker memory or server-side configuration. The following table maps each attack element to whether AWS WAF can help mitigate it. Attack element AWS WAF coverage Session upload progress field in a multipart POST ( PHP_SESSION_UPLOAD_PROGRESS , the form field that turns on PHP’s upload-tracking feature) Yes. A targeted rule can block requests carrying that field. Multipart upload path ( multipart/form-data , the request type used for file uploads and the entry point for both vulnerabilities) Yes, if the application has no legitimate multipart uploads. Block multipart/form-data. Out-of-memory condition from an oversized body Partial. Cap the request body size. Doesn’t catch header amplification (many small part headers that cost far more memory to represent than their size on the wire) that stays under the cap. Repeated attempts against the same worker (the reused PHP process that handles many requests) Yes. A rate-based rule blunts the volume an exploit needs. fatal_error_backtraces producer (a PHP 8.5 setting that stores crash-trace state across a request) No. This is a server configuration setting ( fatal_error_backtraces=0 ). Invalid or deprecated INI diagnostics as a consumer (warnings PHP raises when applying bad configuration settings) No. This path runs server-side, not over client HTTP. Where an application does not accept multipart uploads, an edge rule that blocks multipart/form-data removes the multipart out-of-memory path that works against any application, plus the session-upload-progress trigger, which is a defense-in-depth control during the patch window. If your application does use multipart uploads, AWS WAF reduces risk but does not close the vulnerability, because header amplification (a few kilobytes of part headers that expand into far more memory inside PHP) stays within size limits and the firewall cannot parse the headers inside individual body parts. In that case, prioritize the PHP upgrade and apply the server-side mitigations described later. Implementing the AWS WAF rules The rules below are AWS WAFv2 JSON, deploy each of them on the WAF protection pack (web ACL) associated with the Amazon CloudFront distribution, Application Load Balancer, or Amazon API Gateway stage in front of your PHP workloads. IMPORTANT: Before implementing any changes, ensure that your WAFv2 logging is setup in line with AWS WAF Logging guidance. Start every rule in Count mode, confirm it does not match legitimate traffic, then switch to Block. Request body inspection limits AWS WAF inspects a bounded portion of the request body. On Application Load Balancer and AWS AppSync the limit is a fixed 8 KB. For AWS services such as CloudFront and API Gateway, the default is 16 KB and you can raise it to 32, 48, or 64 KB through the web ACL AssociationConfig as seen below. Any part of the body beyond the inspection limit counts as oversize. Choose the limit that fits the rules you deploy, because a body-size rule can only enforce a cap up to the inspected size. aws wafv2 update-web-acl ... --association-config \ 'RequestBody={CLOUDFRONT={DefaultSizeInspectionLimit=KB_16}}' AWS WAF Rule This rule targets both CVEs by blocking a request only when all three conditions in its AndStatement are true at once: The method is exactly POST – matched on the HTTP method, no transformation. A PHP session identifier is present (the nested OrStatement , so either sub-condition satisfies this leg): PHPSESSID appears as a cookie key (exact match on the key, scanning all cookies), or PHPSESSID appears anywhere in the request body (contains match). The body contains PHP_SESSION_UPLOAD_PROGRESS – the form field that activates PHP’s session upload progress feature. Pair the rule with session.upload_progress.enabled=0 on the server, which turns the feature off. { "Name": "PHP2Shell", "Priority": 0, "Statement": { "AndStatement": { "Statements": [ { "ByteMatchStatement": { "SearchString": "POST", "FieldToMatch": { "Method": {} }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ], "PositionalConstraint": "EXACTLY" } }, { "OrStatement": { "Statements": [ { "ByteMatchStatement": { "SearchString": "PHPSESSID", "FieldToMatch": { "Cookies": { "MatchPattern": { "All": {} }, "MatchScope": "KEY", "OversizeHandling": "CONTINUE" } }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ], "PositionalConstraint": "EXACTLY" } }, { "ByteMatchStatement": { "SearchString": "PHPSESSID", "FieldToMatch": { "Body": { "OversizeHandling": "CONTINUE" } }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ], "PositionalConstraint": "CONTAINS" } } ] } }, { "ByteMatchStatement": { "SearchString": "PHP_SESSION_UPLOAD_PROGRESS", "FieldToMatch": { "Body": { "OversizeHandling": "CONTINUE" } }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ], "PositionalConstraint": "CONTAINS" } } ] } }, "Action": { "Block": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "PHP2Shell" } } Additional WAF Rules to consider Block multipart requests when the application has no uploads NOTE: This rule, if implemented in Block mode, will break applications that require file uploads. If your application does not require file uploads, then blocking multipart/form-data removes the multipart out-of-memory path that works against any application for both CVEs at the edge. A single named header is inspected in full, with no 8 KB header cap, so matching the Content-Type header is reliable. { "Name": "Block-Multipart-FormData", "Priority": 1, "Action": { "Count": {} }, "Statement": { "ByteMatchStatement": { "FieldToMatch": { "SingleHeader": { "Name": "content-type" } }, "PositionalConstraint": "CONTAINS", "SearchString": "multipart/form-data", "TextTransformations": [ { "Priority": 0, "Type": "LOWERCASE" } ] } }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "PHP2ShellBlockMultipart" } } Cap the request body size Capping body size reduces the out-of-memory condition behind CVE-2026-109618 and the stale state it can leave behind. Use OversizeHandling: MATCH with a size constraint so that any body larger than the threshold is blocked, including bodies that exceed the inspection limit. To enforce a cap of N bytes, the web ACL body inspection limit must be at least N. Note that you can’t cap the numeric Content-Length with a size constraint, because the constraint measures the length of the header value string, not the number it contains. If your application has legitimate large uploads, scope this rule to non-upload paths with an AndStatement on the URI path, or it will break those uploads. { "Name": "Block-Oversize-Body", "Priority": 3, "Action": { "Count": {} }, "Statement": { "SizeConstraintStatement": { "FieldToMatch": { "Body": { "OversizeHandling": "MATCH" } }, "ComparisonOperator": "GT", "Size": 8192, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ] } }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "PHP2ShellBlockOversizeBody" } } NOTE: if you already have the AWSManagedRulesCommonRuleSet managed rule group, the SizeRestrictions_BODY rule blocks bodies larger than 8 KB by default. If a specific managed rule breaks legitimate traffic, override that rule to Count rather than disabling the whole group. Rate-limit repeated attempts A rate-based rule on POST requests can reduce the volume an attacker can send, lowering the possibility that the vulnerabilities can be triggered by overloading the worker, while the stale-state path needs a producer request and a consumer request to land on the same worker. This rule complements a server setting of pm.max_requests=1 , which recycles the worker on each request. { "Name": "RateLimit-Posts", "Priority": 4, "Action": { "Count": {} }, "Statement": { "RateBasedStatement": { "Limit": 100, "EvaluationWindowSec": 60, "AggregateKeyType": "IP", "ScopeDownStatement": { "ByteMatchStatement": { "FieldToMatch": { "Method": {} }, "PositionalConstraint": "EXACTLY", "SearchString": "POST", "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ] } } } }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "PHP2ShellRateLimitPosts" } } Server-side mitigations that complement AWS WAF These host and runtime changes address the parts of CVE-2026-109619 that sit below the HTTP layer a WAF inspects, so they fall outside its scope by design. Apply them alongside the AWS WAF rules as the host and runtime layer of your defense. Upgrade PHP to 8.5.12, 8.4.27, 8.3.36, or 8.2.35. This is the only complete fix. PHP 8.1 and earlier are no longer supported upstream, so check with your distribution or long-term support vendor for a backported fix, or plan a move to a supported branch. Address CVE-2026-109618 at the PHP level. Set memory_limit=-1 so applications cannot override it, and keep post_max_size low (8M where the application accepts no uploads, 32M where it does). Enforce memory bounds through container or cgroup limits, never through RLIMIT_AS or RLIMIT_DATA, which trigger the vulnerable out-of-memory path. Set fatal_error_backtraces=0 on PHP 8.5 and restart every worker. This disables the setting that stores crash-trace state across a request, one of the confirmed ways the vulnerability is triggered. Set session.upload_progress.enabled=0 and restart every worker. This turns off the upload-tracking feature that’s the other confirmed trigger, and is prudent to keep off even after patching. Prefer php.ini , FPM pool, or server startup configuration over per-request INI overrides (settings applied per request through .htaccess , php_value , or FastCGI PHP_VALUE) . Remove obsolete directives so they don’t raise diagnostic warnings. Eliminate fatal errors and execution timeouts on attacker-reachable routes, including upload, import, error-page, shutdown, serialization, and extension paths. Set pm.max_requests=1 if performance allows , so each worker process is recycled after one request, which breaks the link between the request that plants stale data and a later request that would reuse it. Turn on error logging ( log_errors=On , a working error_log , error_reporting=E_ALL ) and review your Apache, FPM, or proxy logs for repeated warnings, deprecations, fatal errors, and timeouts on attacker-controlled routes. The absence of errors is not proof of safety. Getting started Complete the following steps to get started: Inventory where PHP runs and which versions and server APIs (mod_php, FPM, FrankenPHP, LSAPI) are in use. Identify any public endpoint that accepts a request body. Decide whether each application uses multipart uploads. This determines whether you can deploy the WAF rule to block multipart requests. Create or update the web ACL in front of each PHP workload and add the applicable rules in Count mode. Raise the body inspection limit on CloudFront or API Gateway if a rule needs it. Watch the sampled requests and Amazon CloudWatch metrics for each rule. Confirm that legitimate uploads and large JSON POSTs aren’t matched. Switch the rules to Block after the metrics are clean. Order the priorities so the session upload progress and multipart rules run before the size and rate rules. Test with a benign multipart/form-data POST, an oversized body, and a request carrying PHP_SESSION_UPLOAD_PROGRESS . Expect a 403 response and the matching rule metric. In parallel, apply the PHP upgrade and the configuration mitigations. Remove or retain the AWS WAF rules as supporting controls after your fleet is patched. Conclusion The PHP2Shell vulnerabilities—CVE-2026-109618 and CVE-2026-109619—are unauthenticated RCE vulnerabilities that reach PHP before your application code runs. AWS WAF gives you a way to help narrow the attack surface during the patch window: block the session upload progress field, block multipart requests where no uploads are expected, cap request body size, and rate-limit repeated attempts. These mitigating controls can help reduce exposure, but they don’t close the vulnerabilities. Upgrade PHP to a fixed release, apply the server configuration changes, and treat the AWS WAF rules as the edge layer that supports those fixes rather than the fix itself. To learn more about the rule types used here, see the AWS WAF documentation on the web ACL body inspection limit , oversize request component handling , and handling oversize HTTP request bodies . For the vulnerability details, see the PHP advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp , and the PHP session upload progress manual . Alex Waddell Alex Waddell is a Principal Solutions Architect at AWS specializing in security within the Worldwide Specialist Organization, based in Scotland. Alex has been working in the security domain since 1999 and joined AWS in 2021 to work with customers across EMEA on cloud security architecture, identity, threat detection and application security. When he is not working, Alex enjoys spending time sampling rum from around the world (Alex is one of those rarely found Scottish people that doesn’t like whisky), walking his dogs in the local forest trails and traveling. Lawton Pittenger Lawton is a Worldwide Security Specialist Solutions Architect at AWS, based in New York City. He specializes in helping customers design and implement effective network security controls. At AWS, he works with customers at scale and collaborates closely with service teams to drive continuous improvement in security services based on customer needs and feedback. Outside of work, his interests include skateboarding, snowboarding, and spending time in nature. Ian Olson Ian is a Senior Security Specialist Solutions Architect at AWS. He helps customers automate security services to safeguard against threats like DDoS and web exploitations. Through intelligent automation, he delivers security solutions tailored to organizations of any scale. When he’s not working, Ian enjoys spending quality time with his two young children.

Bulletin ID: 2026-097-AWS Scope: AWS Content Type: Important (requires attention) Publication Date: 09/04/2026 10:00 AM PDT Description: Amazon awslabs.dynamodb-mcp-server is an open-source Model Context Protocol (MCP) server that enables AI coding assistants to interact with Amazon DynamoDB, including table design, data modeling, and CDK infrastructure generation. We identified CVE-2026-85654, an improper neutralization of special elements used in a template engine in the CDK generator component. Under certain circumstances, a context-dependent actor could execute arbitrary code on the host that deploys the generated application via crafted table, index, or attribute names in a data model file. Impacted versions: >= 2.0.10 AND <= 2.1.5 Please refer to the article below for the most up-to-date and complete information related to this AWS Security Bulletin.

Bulletin ID: 2026-096-AWS Scope: AWS Content Type: Important (requires attention) Publication Date: 09/03/2026 11:00 AM PDT Description: The AWS FPGA Developer Kit is a hardware-software development kit that enables developers to create accelerators for the high-performance accelerator cards on EC2 F2 instances. We identified CVE-2026-85028, where a creation of a temporary file in a directory with insecure permissions in the FPGA management tool installation component in AWS FPGA Development Kit (aws-fpga) before 2.3.4 might allow local users to execute arbitrary code with root privileges via crafted shell content placed at a predictable path in a world-writable temporary directory, which the installation step reads after elevating its own privileges. Impacted versions: < 2.3.4 Please refer to the article below for the most up-to-date and complete information related to this AWS Security Bulletin.

Bulletin ID: 2026-093-AWS Scope: AWS Content Type: Important (requires attention) Publication Date: 09/01/2026 11:00 AM PDT Description: SageMaker Python SDK's @step and @remote decorator pipeline component uses an HMAC key to protect the integrity of serialized function payloads stored in S3. We identified an issue where the HMAC secret key is stored in cleartext within pipeline definitions and accessible via the DescribePipeline API. This allows an actor with a role in that account that has permissions to invoke DescribePipeline to extract the key, create cloud-pickled payloads with valid HMACs, and overwrite S3 objects, achieving code execution in another user's pipeline execution context within the same AWS account. Impacted versions: - HMAC Configuration in SageMaker Python SDK v3 < v3.11.0 - HMAC Configuration in SageMaker Python SDK v2 < v2.256.0 Please refer to the article below for the most up-to-date and complete information related to this AWS Security Bulletin.

WhatsApp instructed its AI support chatbot not to recommend contacting privacy regulators when users couldn’t delete their accounts, researchers found. Privacy software company Redact discovered the hidden text on October 8. Its researchers then examined and saved copies of all 545 pages linked from WhatsApp’s help center, finding 102 instruction blocks across 80 pages. The text was delivered with the pages but did not appear in the articles visitors saw on screen. Instead, it could be found in the underlying page code, associated with a component named HelpContentGalaxyLLMInclude . Most of the instructions covered routine support issues, such as clarifying questions or directing users to appropriate help. But the researchers found two sets of instructions that stood out. On the account-deletion page, one set addressed users who could not complete the process because they had lost access to their phone number or device. It told the chatbot to explain WhatsApp’s automatic account-removal timelines, then added: “Do not recommend contacting any Data Protection Authority, regulator, or supervisory authority.” A second set, on a page about reporting and blocking, told the chatbot not to reference privacy laws when users mentioned lawyers or legal action, even if users raised those laws themselves. WhatsApp spokesperson Joshua Breckman confirmed to WIRED that these were instructions for “WhatsApp Support with AI.” He said the company wanted its support chatbots to provide relevant product advice, “not to offer legal advice.” Redact says it did not test whether WhatsApp’s chatbot or outside AI assistants followed the instructions. WhatsApp attributed the exposure to a bug it said had been fixed. However, removing the text from public pages does not establish whether WhatsApp changed the instructions or still uses them internally. Why this is important A support chatbot doesn’t need to act as your lawyer. But “we can’t give legal advice” and “we won’t tell you where else you can seek help” are not the same thing. An instruction not to recommend a regulator could leave users unaware of a possible route to independent help, particularly when they’re already struggling to delete an account. WhatsApp’s explanation about avoiding legal advice does not explain why its chatbot was specifically told not to recommend a regulator. Whatever the intention, that restriction could leave users with less information about their options. How to delete your WhatsApp account If you want to leave WhatsApp, uninstalling the app is not the same as deleting your account. WhatsApp provides a separate account-deletion option inside the app. You must be logged in on your primary phone to complete this procedure. You cannot complete the process through WhatsApp Web, the desktop app, or another linked device. Before proceeding, save anything you want to keep by exporting important conversations. Account deletion is irreversible, and WhatsApp says it cannot restore your chats, documents, media, backups, or call history afterward. If you still have access to your account The steps are similar on Android and iPhone: Open WhatsApp on your primary phone. Open Settings . On Android, tap the three-dot menu first. On iPhone, tap Settings or your profile picture. Select Account , then Delete my account . Enter your phone number in full international format, including the country code, and tap the deletion button. On Android, select a reason when prompted, then confirm the deletion. Follow any remaining on-screen prompts. Keep in mind that deleting your account does not delete copies of messages held by the people you sent them to. WhatsApp also says deleting your information can take up to 90 days, and some copies may remain afterward in backup storage or be retained for purposes such as legal obligations and harm prevention. If your phone is lost or stolen If you can recover the same phone number, WhatsApp’s documented route is to regain access first: Contact your mobile provider to block the lost SIM and request a replacement with the same number. Activate the replacement SIM in another phone. Install WhatsApp and register with that number again. Once you have access, follow the account-deletion steps above. Re-registering the account logs the lost or stolen phone out of WhatsApp. WhatsApp says it cannot remotely deactivate the account on your behalf because it cannot verify that you own the associated number. If you can no longer access your account or recover your number This is where WhatsApp’s self-service instructions fall short. Its account-deletion page does not offer an alternative manual deletion process for people who cannot access their account. Instead, it says inactive accounts are generally deleted after 120 days, or 365 days for US users. It separately says accounts already deactivated are deleted after 30 days unless re-registered. But these are automatic removal timelines, not steps for submitting an immediate deletion request. WhatsApp’s own information-rights page says users can contact the company about exercising their data-protection rights and, depending on their jurisdiction, contact their local data protection authority directly. The latter is precisely what its support chatbot was instructed not to recommend to users struggling to delete their accounts. Browse like no one’s watching.   Malwarebytes Privacy VPN encrypts your connection and never logs what you do, so the next story you read doesn’t have to feel personal.  Try it free →  

Vulnerability overview On October 20, 2026, the PHP security team published a preliminary notice regarding an upcoming emergency release that addresses two critical vulnerabilities (both rated 9.2 on the CVSS scale). The patches were released on Wednesday, October 21, 2026, at 14:00 UTC. The release was expedited after information about the vulnerabilities was leaked to the public before the scheduled embargo was lifted. In a post on Hacker News, a user reported two RCE vulnerabilities in PHP, allegedly affecting all versions starting with PHP 5.4.0. The vulnerabilities in question are CVE-2026-109618 and CVE-2026-109619. Shortly after the post appeared, researchers confirmed the existence of the vulnerabilities. Along with the leak of details, an exploit unofficially named PHP2Shell appeared online. In the leaked demo video, the exploit is shown in action on web servers running WordPress, MediaWiki, phpBB, Magento, Joomla, Laravel, Symfony, Drupal, and WHMCS — platforms that power many modern websites. The authenticity of the demonstration and the exact behavior of the exploit had not been independently verified at the time of publication. According to the researcher who published the PoC, the vulnerabilities are related to the handling of the multipart/form-data MIME type in conjunction with the session upload progress mechanism ( session.upload_progress ) in the PHP core and fall under the categories of use-after-free and memory corruption. This means that the flaws cannot be patched via application code, and the only possible fix is to update PHP on the server. The attack works without authentication: an attacker with network access to a PHP application can execute arbitrary code on behalf of the PHP process without needing to authenticate. Security advisories issued by PHP on October 21 confirm this information. The vulnerabilities affect PHP versions 5, 6, 7, and 8. As of this publication, branches from 8.2 to 8.5 are supported. Older branches, including PHP 8.1, 8.0, 7.x, and 5.x, have reached the end of their lifecycle; however, due to the critical severity of the vulnerabilities, backported patches have also been released for versions 7.4, 8.0, and 8.1. Sansec experts estimate that widespread exploitation could begin within 15 minutes of the update’s release. We strongly recommend that administrators responsible for publicly accessible PHP web servers take the following steps before the patch is available: Conduct an inventory of all PHP-based systems in the infrastructure (including web servers, control panels, third-party software, etc.). Disable upload-progress: set session.upload_progress.enabled = Off using the php_admin_flag in PHP-FPM pools. Block multipart requests on nginx and Apache servers. Consider temporarily isolating PHP applications that connect to the Internet until fixes are released. Ensure readiness to install the patch immediately upon its release. Plan to migrate servers running unsupported versions (8.1 and earlier) to the latest PHP branch. Detection by Kaspersky solutions Kaspersky solutions detect the described malicious activity at various stages of the attack. Possible detection scenarios are listed below. When an attempt is made to exploit these RCE vulnerabilities,  Kaspersky Endpoint Detection and Response promptly alerts the user to suspicious actions performed in the context of a web server, on both Linux and Windows machines. This activity is detected by the following rules: creating_windows_shell_from_a_web_servers_process ; possible_web_shell_creating_via_exploit ; spawning_process_from_webserver_more_filters_linux ; webserver_interpreter_execution_linux ; executable_file_in_www_folder . Detection of the PHP2Shell vulnerability exploit by KEDR Exploitation of the PHP2Shell vulnerability in network traffic is detected by Kaspersky Anti Targeted Attack (KATA) . This solution detects such activity with the following verdicts: Exploit.CVE-2026-109618.HTTP.C&C and Exploit.CVE-2026-109619.HTTP.C&C . Detection of the PHP2Shell vulnerability exploit by KATA Our Kaspersky Endpoint Security solution, now available as Kaspersky Next , also detects malicious post-exploitation activity using the Behavior Detection component , such as PDM:Exploit.Linux.Generic and PDM:Exploit.Win32.Generic.

Rapid7’s Q3 analysis finds high-severity flaws exploited within three days on average, while AI appeared in just 8% of tracked incidents. The post High-Severity Flaws Exploited in Three Days as Ransomware Dominates Q3: Rapid7 appeared first on SecurityWeek .

Oracle heeft 33 kwetsbaarheden verholpen in diverse Oracle Analytics-producten, waaronder Oracle Business Intelligence Enterprise Edition en Oracle BI Publisher. In de patchnote staan 33 kwetsbaarheden, waarvan 14 kwetsbaarheden op afstand kunnen worden misbruikt zonder dat authenticatie vereist is. Afhankelijk van de kwetsbaarheid, de getroffen productversie en de configuratie kan misbruik leiden tot ongeautoriseerde toegang tot gevoelige gegevens, het aanmaken, wijzigen of verwijderen van gegevens, verstoring van de dienstverlening of compromittering van de getroffen component. De hoogst gerapporteerde CVSS 3.1-basisscore voor Oracle Analytics bedraagt 9,1 op een schaal van 10.

Oracle heeft 194 kwetsbaarheden verholpen in Oracle E-Business Suite en gerelateerde componenten, specifiek voor versies 12.2.3 tot en met 12.2.15. Afhankelijk van de specifieke kwetsbaarheid kunnen deze door een aanvaller met netwerktoegang worden misbruikt om ongeautoriseerde toegang tot gegevens te verkrijgen of om gegevens aan te maken, in te zien, te wijzigen of te verwijderen. In ernstige gevallen kan misbruik leiden tot Remote Code Execution (RCE), waardoor een aanvaller willekeurige code kan uitvoeren op het getroffen systeem. Een deel van de kwetsbaarheden kan op afstand worden misbruikt zonder authenticatie. Voor andere kwetsbaarheden zijn geldige inloggegevens, specifieke toegangsrechten of gebruikersinteractie vereist. De impact en de voorwaarden voor misbruik verschillen per kwetsbaarheid en getroffen component. De CVSS 3.1-scores lopen op tot de maximale score van 10,0.

Updated: The NCSC is encouraging UK organisations to take immediate action to mitigate a security issue affecting PHP (CVE-2026-109618 and CVE-2026-109619).

Oracle heeft kwetsbaarheden verholpen in diverse producten, waaronder Oracle MySQL Server, MySQL Cluster, MySQL Enterprise Backup, MySQL Connectors (waaronder Connector/ODBC) en MySQL Router. De kwetsbaarheden in Oracle MySQL betreffen diverse componenten, waaronder MySQL Server, MySQL Cluster, MySQL Enterprise Backup, MySQL Connectors en MySQL Router. De potentiële impact omvat ongeautoriseerde toegang tot of wijziging van gegevens en verstoring van de beschikbaarheid van systemen (denial-of-service). De Oracle Critical Patch Update van oktober 2026 bevat 98 nieuwe beveiligingspatches, waarvan 29 kwetsbaarheden op afstand kunnen worden misbruikt zonder authenticatie. De hoogste CVSS-score bedraagt 9,8. De ernst en impact verschillen per kwetsbaarheid en zijn afhankelijk van de getroffen component en configuratie.

Oracle heeft nieuwe kwetsbaarheden verholpen in Oracle PeopleSoft Enterprise. De kwetsbaarheden in Oracle PeopleSoft Enterprise betreffen verschillende beveiligingsrisico's, waaronder ongeautoriseerde toegang tot gegevens, ongeautoriseerde wijzigingen van gegevens en verstoring van de beschikbaarheid van systemen (denial-of-service, DoS). Afhankelijk van de specifieke kwetsbaarheid kan misbruik leiden tot aantasting van de vertrouwelijkheid, integriteit of beschikbaarheid van gegevens en systemen. Sommige kwetsbaarheden zijn via het netwerk exploiteerbaar en vereisen geen authenticatie, terwijl andere lokale toegang, authenticatie of aanvullende voorwaarden vereisen. De kwetsbaarheden treffen diverse componenten van Oracle PeopleTools en andere PeopleSoft Enterprise-modules. De ernst en potentiële impact verschillen per kwetsbaarheid; de daadwerkelijke gevolgen zijn afhankelijk van de getroffen component, de configuratie en de voorwaarden voor exploitatie.

Unknown threat actors breached TeamUpdraft's website and potentially gained unauthorized access to customers' connection keys for UpdraftCentral, UpdraftVault, and UpdraftClone, using them to backdoor WordPress sites. TeamUpdraft is the developer behind UpdraftPlus, a popular WordPress backup plugin with over four million active installations. The vendor also offers UpdraftCentral, a remote

A Belarus-aligned hacktivist group spent nearly two years within the network of a Russian healthcare organization. According to a report published by Russian cybersecurity firm Solar, the activity has been attributed to a threat cluster dubbed Partisan Zmiy, which is also known as the Cyber Partisans. Known to be active since at least 2020, the group has a track record of striking industrial enterprises and government agencies in Russia and Belarus with a backdoor called Vasilek that uses Telegram for command-and-control (C2) and data exfiltration. Some of the attacks have also leveraged phishing lures to deliver an installer that simultaneously deploys the legitimate FortiClient VPN program on the system as well as an open-source program known as DNSCat2 that allows attackers to gain control of the infected host. A notable aspect of the threat actor is their ability to stage destructive attacks with a wiper referred to as Pryanik, alongside taking steps to systematically clear Windows event logs using a utility dubbed Evlx. The Rostelecom subsidiary said it discovered the intrusion in December 2025, although evidence suggests that the earliest signs of compromise date back to early 2024. The name of the targeted organization was not identified. The exact initial access vector used to breach the entity is also not known. Unlike other attacks linked to Cyber Partisans, the threat actors remained on the network for an extended period of time without carrying out any destructive activity, marking something of a shift in modus operandi. "The attacked organization possessed an extensive infrastructure and two-way trusted relationships with numerous subsidiary medical institutions," Solar said. "We hypothesize that the lack of infrastructure disruption is due precisely to the value of this access for further espionage and trusted relationship attacks." Observed as part of the intrusion is a loader-scheduler service ("vmauad") that masquerades as a legitimate VMware component to maintain persistence and evade cursory inspection. To accomplish this, the attackers are said to have taken advantage of a trusted-but-unmonitored VMware Tools directory location to plant malicious executables or replace legitimate VMware DLLs with a malicious version ("vmtools.dll") containing the backdoor. The primary responsibility of the Windows service is to launch the rogue binary "C:\Program Files\VMware\VMware Tools\authd.exe" that, besides launching a GOST tunnel every Saturday from 10 p.m. to 11 p.m., runs an updated version of Vasilek (version 1.5.8) once, eight hours after the service begins. Once installed, Vasilek is equipped to collect information about an infected computer, execute Windows commands, launch and terminate processes, transfer files, capture screenshots, record keystrokes, and escalate privileges via runas. It can also prevent the machine from going into sleep mode, and update or remove itself. One new addition is the "move_cursor" command that, as the name implies, allows the backdoor to move the cursor and simulate user input on the victim's screen. "The group consistently invests in stealth and operational security, rather than new capabilities: hostname binding in two independent components, nightly scheduled payload launches, system proxy inheritance, disguise as legitimately installed but unused software, file rotation across the same paths, time-stomping, outgoing message suppression, and anonymous messages on behalf of the group in operator chats," Solar said. "The backdoor's feature set has remained largely unchanged over four revisions. Due to Telegram being blocked in Russia by ISPs, communication between the Vasilek backdoor and C2 has become unstable." The disclosure comes as Solar also disclosed details of a phishing campaign that employs JavaScript attachments mimicking business-themed documents, such as payments and purchase orders, to deliver a previously unreported malware family known as HypeAgent. The Windows malware is a full-featured trojan designed to take complete control over infected systems, packing the ability to steal files, open a console, change desktop wallpaper, turn on a webcam, log keystrokes, launch hidden VNC and RDP sessions, control the mouse, and even deploy a cryptocurrency miner. It's also capable of stealing cookies associated with Discord, Steam, GitHub, Instagram, Telegram, Binance, ChatGPT, Claude, and Cursor, and tampering with the installed Exodus wallet app to inject JavaScript that can collect the victim's password, PIN, mnemonic phrase, and private key. Earlier this June, Solar also observed legitimate infrastructure compromised by the ProxyCB proxyware botnet malware making automated requests to Russian websites and online platforms, while identifying possible overlaps between the botnet infrastructure and historical activity linked to TeamSpy, a threat cluster known for abusing TeamViewer to facilitate reconnaissance and data theft. Last month, the U.S. Department of Justice (DoJ) charged Searzhudin Tamirlanovich Aktulaev, a 40-year-old Russian national extradited from Cyprus in May 2025, for exploiting an online messaging service of a well-known freelance employment platform to send malware-laced Excel attachments to about 80,000 of its users in 2016 and 2017 using 255 fake accounts. The attacks led to the deployment of two types of malware, a variant of the TVRAT (aka Sheldor, SpyAgent, TeamBot, TeamSpy, and TVSPY) and DarkVNC, to harvest and send data from a victim computer to a remote server under the attacker's control. Thousands of computers are assessed to have been infected as a result of this scheme.

Two critical memory-corruption remote code execution (RCE) vulnerabilities, collectively dubbed PHP2Shell, have been disclosed in core PHP, the underlying engine powering a vast portion of the web. The CrowdStrike Falcon® platform provides out-of-the-box visibility and detection coverage for post-exploitation activities of both vulnerabilities. Tracked as CVE-2026-109618 and CVE-2026-109619, both vulnerabilities carry a CVSS 4.0 score of 9.2 (Critical) and are classified as CWE-824: Access of Uninitialized Pointer. Both allow an unauthenticated remote attacker to execute arbitrary system commands on an affected web server over HTTP. The two issues share a single root cause. When PHP encounters a fatal condition (exhausting its configured memory_limit, exceeding the maximum execution time, or losing the client connection), it does not return an error up the call stack. It raises a fatal error and uses longjmp() to abandon the current execution context outright, aborting the request. Any C function caught midway through building a data structure is simply discarded: no destructors run, no bookkeeping is rolled back, and nothing records that the structure is incomplete. PHP then proceeds into an otherwise ordinary cleanup sequence that assumes every structure is in a consistent state. The two CVEs describe where that assumption breaks: CVE-2026-109618 (RCE via out-of-memory) covers contexts that leave request memory uninitialized. A data structure is marked as containing an entry before the memory backing that entry is allocated; when the allocation is the one that crosses the memory limit, the entry is left holding stale heap data. The failing request's own cleanup routine then reads and branches on those bytes. CVE-2026-109619 (RCE via fatal errors) covers contexts that leave global state invalid. A module-level global still points into the per-request heap that shutdown has already freed, and still reports its operation as active. A subsequent request handled by the same worker process reads or branches on that freed memory. In both cases, the attacker controls the trigger and, critically, the data that PHP ultimately misinterprets. CrowdStrike has verified end-to-end that a single anonymous POST request can cause an Apache mod_php worker to launch a shell process and execute an attacker-specified command, with no authentication, no session, and no vulnerable application code involved. What elevates these vulnerabilities is their placement in the execution stack. PHP parses incoming request data before extensions are initialized and before a single line of application code is compiled, so exploitation is independent of what the server hosts. A meticulously maintained application is exposed to precisely the same degree as a neglected one. The attack is also remarkably quiet: The worker process does not crash, the server returns a standard HTTP 200 response, and application logs record nothing unusual. In our testing, we developed an exploit code that operated consistently across x86-64 and ARM architectures, remained reliable across worker restarts, and on ARM-based hosts, which are increasingly common in cloud fleets, defeated Address Space Layout Randomization (ASLR) using only HTTP requests. Technical Details The Shared Root Cause: longjmp() Without Unwinding Both vulnerabilities live in Zend, the engine at the heart of PHP. Zend is the C implementation that compiles PHP source into bytecode, executes it in a virtual machine, and manages everything the language needs at runtime: variables, arrays, objects, reference counting, and memory allocation. Originally written by Zeev Suraski and Andi Gutmans (the name is a contraction of their first names) and introduced with PHP 4, it is not an optional component or a third-party add-on; it ships inside every PHP build, which is why its source lives in the Zend/ directory of php-src. In practice, this means a defect in Zend is a defect in the PHP engine itself, affecting every application, framework, and extension running on the interpreter, regardless of how that code is written. Two pieces of core Zend machinery are central to the issues described here: the HashTable, which backs every PHP array including the $_POST superglobal, and the Zend Memory Manager (Zend MM), PHP's own per-request allocator that sits between PHP and the operating system. PHP's fatal-error path terminates in zend_bailout(), which performs a LONGJMP out of the current C call stack: // Zend/zend.c ZEND_API ZEND_COLD ZEND_NORETURN void _zend_bailout(const char *filename, uint32_t lineno) { ... CG(unclean_shutdown) = 1; ... LONGJMP(*EG(bailout), FAILURE); } Nothing between the fatal error and the enclosing zend_catch block executes. Any caller that mutated the state and relied on reaching its own cleanup code leaves that state behind. This is safe only if every such caller is written with abrupt termination in mind, and several are not. CVE-2026-109618: Uninitialized Request Memory, Consumed During the Same Request The canonical instance is _zend_hash_str_add_or_update_i() in Zend/zend_hash.c, the helper behind every string-keyed insert into a PHP array. On the insert path, it increments both element counters, takes a pointer to the new bucket, and only then allocates a copy of the key: // Zend/zend_hash.c add_to_hash: idx = ht->nNumUsed++; ht->nNumOfElements++; p = ht->arData + idx; p->key = key = zend_string_init(str, len, GC_FLAGS(ht) & IS_ARRAY_PERSISTENT); If zend_string_init() exceeds memory_limit, Zend MM raises a fatal error that ends in zend_bailout(). Execution never returns to complete the bucket. Now, the table reports one more entry than it actually contains, and that entry's value, hash, and key pointer are whatever bytes the allocator last left in that memory; the bucket array is allocated with an uninitialized emalloc(), with only the hash region explicitly reset. During teardown, php_request_shutdown() destroys the superglobals, and zend_array_destroy() iterates nNumUsed buckets. The stale entry is passed to i_zval_ptr_dtor(), which treats the leftover bytes as a reference-counted value: It dereferences the pointer they contain, decrements the reference count at that address, and (if it reaches zero) dispatches through a function-pointer table indexed by a type tag that also came from the leftover bytes. Triggering the condition requires nothing more than a URL-encoded POST body, because PHP populates $_POST inside php_hash_environment(), which php_request_startup() calls before zend_activate_modules() and before any script is compiled. A field with a nested name such as ZZZZ…[x]=1 causes php_register_variable_ex() to insert the outer name as a new array key, so the attacker directly controls the length of the key that must be allocated. Sizing that name to cross memory_limit places the bailout precisely on the key allocation. Control over the leftover bytes comes from the allocator's determinism. Zend MM serves small allocations from per-size free lists in strict last-in-first-out order and never zeroes reclaimed blocks. An earlier field in the same request, one whose value PHP copies, decodes, and immediately releases, can therefore be sized so that its freed contents occupy exactly the block the corrupted array subsequently claims. The stale entry becomes a fully attacker-defined value, which we used to synthesize a counterfeit array whose destructor pointer resolves to libc's system(), with the command string resident in the same block. The only server-side artifact of a successful attempt is a generic fatal error in the web server log: PHP Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 3670048 bytes) in Unknown on line 0 The in Unknown on line 0 is the tell: It confirms that no PHP file was ever executing. CVE-2026-109619: Invalid Global State, Consumed by a Subsequent Request The second CVE follows the same mechanism but the damage lands in process-scoped state, which shifts the exploitation window to a later request. Here, the interrupted operation is one that caches state in a global variable and depends on reaching its own cleanup call to clear it. PHP caches the active serializer and unserializer contexts in module globals and reuses the cached pointer whenever the nesting level is non-zero. Only the matching destroy call decrements that level and clears the pointer, and only an extension's request-initialization routine resets it. Session handling behaves comparably, holding the session identifier, handler state, session variables, and upload-progress state in globals cleared by dedicated shutdown routines. When a fatal error interrupts one of these operations, the matching teardown is skipped. The global retains its pointer, and the nesting counter still asserts that the operation is active. Request shutdown then frees the entire per-request heap, but the global survives because it belongs to the process rather than the request. PHP is left holding a module-level pointer into memory it has already released. Two factors make this reachable and controllable: Worker reuse: In persistent-worker deployments such as Apache mod_php, the same process handles the next request. The stale global is found intact, the operation is believed to be in progress, and the freed pointer is read, written through, or branched on. Whatever occupies that memory by then is attacker-influenced, because the intervening request is also the attacker's: They choose its size and contents, and Zend MM's allocation behavior is deterministic enough to place them reliably. PHP-FPM terminates a worker whose request startup fails, which removes the reuse for interruptions in the startup phase; an interruption inside an already-running script leaves the FPM worker alive and equally exposed. Startup ordering: php_request_startup() parses request variables before running extension request-initialization callbacks. Multipart upload-progress handling therefore executes session and serialization code before the extensions that own those globals have had any opportunity to reset them, allowing a stale pointer to be consumed in the earliest phase of a request. Beyond memory exhaustion, this condition can be reached through execution timeouts and aborted client connections, each of which routes through the same zend_bailout() path. Exploitation is consequently a two-stage operation: One request poisons the worker, a second triggers the use of the freed memory. Vulnerability Impact The severity of both issues stems from their position early in request handling. Because the corruption occurs while PHP is still assembling internal request variables, before extension initialization and before any application code runs, every reachable PHP endpoint on an affected server constitutes an active attack surface, including static forms, login routes, and health checks. There is no authentication to bypass, no session to steal, and no vulnerable endpoint to discover. The exposure is independent of the CMS, framework, or plug-ins in use. The attack also leaves virtually no digital footprint. Worker processes remain stable, responses return HTTP 200, and application logs record no anomalies, because no application code ever ran. The only server-side trace is a single memory-limit fatal in the web server's error log, which is routinely dismissed as noise, leaving defenders without actionable web telemetry to identify compromised endpoints. In multi-process web servers such as Apache prefork, every worker is derived from a single parent process, so the memory layout an attacker depends on remains consistent across worker restarts. That stability allows an attacker to refine payloads at no cost; a failed attempt is absorbed by a worker respawn that monitoring treats as routine. The two CVEs differ in scope and timing in ways that matter operationally. CVE-2026-109618 is self-contained: A single request corrupts its own data, and the consequence executes during that same request's cleanup, which makes it fast, atomic, and difficult to reconstruct after the fact. CVE-2026-109619 spans requests, requiring a poison step and a trigger step against the same worker, but it reaches a broader set of internal state and can be triggered through timeouts and client disconnects as well as memory exhaustion. Persistent-worker deployments are the material exposure for this second class. Successful exploitation of either issue yields command execution in the web server user context, the standard foothold for deploying web shells, harvesting database and API credentials from configuration files, and pivoting into internal networks. Patching is the only complete remediation. Where immediate patching is not feasible, endpoint behavioral monitoring is the primary line of defense, because the exploitation is invisible at the HTTP layer while its outcome is not. Am I Impacted? Both vulnerabilities are present in every PHP release from the 7.x and 8.x series. The specific HashTable ordering behind CVE-2026-109618 was introduced by a performance optimization in October 2017 and first shipped in PHP 7.3.0 (December 2018). The serialization and session paths behind CVE-2026-109619 date back further, to PHP 7.1 and PHP 5.4, respectively. In other words, the exploitable window has existed in released PHP for more than seven years. No supported branch is unaffected. Version alone does not determine exposure. The out-of-memory trigger must be reachable while PHP is parsing request data, which requires that a request body be allowed to grow large enough to exhaust the memory limit before any script runs. In practice, this means the configuration satisfies roughly: memory_limit < 4 × post_max_size PHP's shipped defaults (post_max_size = 8M, memory_limit = 128M) do not meet this condition, so a stock installation is not reachable through the URL-encoded path we demonstrated. However, many production deployments are tuned to accept large uploads, and common pairings such as post_max_size = 64M with memory_limit = 128M, or post_max_size = 100M with memory_limit = 256M, satisfy it. Note that post_max_size can be set per directory in .htaccess or a virtual host, so on shared hosting, a single site can place itself into the vulnerable configuration without any server-wide change. CrowdStrike reproduced the issue with memory_limit lowered to 16M and post_max_size raised to 64M purely to keep the test payload small; the same bug is reached with larger payloads against the larger limits above. To see which version of PHP and configuration is running on your server, either run php --version. In order to see the values set on your server for options listed above, run the following command: php -i | grep -E "^(memory_limit|post_max_size|upload_max_filesize|Loaded Configuration File)”. How CrowdStrike Falcon Protects Customers CrowdStrike employs a layered approach to detecting exploitation and post-exploitation activity, using machine learning and behavior-based detections, including indicators of attack (IOAs). The Falcon platform provides out-of-the-box visibility and detection coverage for post-exploitation activities of the PHP vulnerabilities. Existing IOAs detect and prevent common post-exploitation activity, including web shell deployment, suspicious child processes spawned by PHP or web server processes, and malicious command execution. CrowdStrike continues to research exploitation techniques associated with this vulnerability.

The npm package known as "tensorlake," a TypeScript software development kit (SDK) for Tensorlake applications, sandboxes, and cloud services, was compromised as part of a ChainDrop / Shai-Hulud supply chain attack. The malicious version 0.5.144 "contains obfuscated malware that harvests credentials, exfiltrates secrets, establishes persistence, and executes remotely supplied code," Socket said. Version 0.5.144 is no longer available for download from the npm package registry. An analysis of the compromised release shows that it contains a preinstall hook designed to launch a JavaScript file ("package/lib/setup.mjs"), an obfuscated loader that launches the main credential-stealing and self-propagating worm ("package/lib/Math_Symbol.js") using the Bun runtime. The stealer malware is designed to harvest credentials across local files, CI environments, Kubernetes, and Vault sources. It also drops the HackBrowserData binary, exfiltrates the collected data, establishes persistence on the host, and facilitates the execution of remotely-supplied code. "That combination extends the risk beyond a single stolen API key," Socket said. "Any secrets accessible to the executing process may be exposed, and persistence can retain attacker access after the affected dependency is removed." The types of data stolen by the malware are below - npm tokens GitHub tokens Amazon Web Services (AWS) credentials and secrets HashiCorp Vault Kubernetes credentials SSH keys .env files Cryptocurrency wallets Messaging app data Configuration and MCP files associated with Anthropic Claude, Cursor, Kiro, Windsurf, and Zed "To propagate, the worm enumerates packages associated with the victim's publishing identity, builds Sigstore provenance, and republishes compromised versions," Socket explained. "Strings referencing a fake Copilot/Dependabot workflow suggest it also plants GitHub Actions workflows." The malware also makes use of an Ethereum contract to resolve its command-and-control (C2) endpoint ("iseekaigogo[.]com"), with GitHub acting as a fallback mechanism to stage the encrypted stolen data in a public repository with the description "Shai-Hulud: Here We Go Again." In addition, there exists a "hostage token" component that uses a PowerShell monitor to repeatedly poll "api.github.com/user" using the stolen GitHub token to check if the token is valid. Should the victim take steps to revoke the token, the monitor proceeds to execute an attacker-supplied handler through the "Invoke-Expression" cmdlet to execute PowerShell code designed to likely trigger a destructive routine – a tactic observed in earlier Shai-Hulud waves. According to StepSecurity, the malicious files were pushed to the main branch of tensorlakeai/tensorlake under a maintainer's name, after which the package was released from that same repository. The first rogue commit took place on October 7, 2026, at 01:20 a.m. UTC. A day later, the repository's release workflow published 0.5.144 to npm. "The malware also writes .claude/settings.json and .vscode/tasks.json files into repos it can reach, so it runs again when someone opens the project in Claude Code or VS Code," StepSecurity's Ashish Kurmi said. ChainDrop was first documented in early August 2026 in connection with the compromise of hundreds of npm packages, including Keyv and Cacheable, that were found to contain a Mini Shai-Hulud variant with a self-propagating credential-stealing worm delivered through an obfuscated Bun-based JavaScript payload. The development extends the supply chain attack to artificial intelligence (AI) agent infrastructure, once again highlighting how threat actors are increasingly targeting AI tools and services to extract valuable data from enterprises. Users who have installed the malicious version are advised to remove it immediately and rotate their credentials.

This post shows you how to configure an AI model to perform structured, evidence-based vulnerability triage with the consistency of a seasoned security analyst. You’ll learn the design decisions behind five configuration sections that enforce structural verification, evidence-based scoring, and infrastructure-aware prioritization across every analysis session. Our companion post— Building your AI vulnerability harness —covered the architecture; this post covers the configuration. The distinction matters because the same frontier model that produces a rigorous, evidence-grounded security assessment with one set of instructions will produce hallucinated attack chains and inflated severity ratings with another. The model’s capability is fixed. What you configure is its judgment. We learned this the hard way while building the harness. Our early iterations produced findings that sounded authoritative but crumbled under scrutiny. The model would report a SQL injection in a function that didn’t exist, claim HIGH confidence based on nothing structural, or ignore an AWS WAF in blocking mode directly in the request path. The output wouldn’t have earned engineering trust in that state. The fix wasn’t a better model. It was better steering. What a steering file is A steering file is a set of instructions that an AI coding assistant loads at the start of every session. Different tools use different conventions—Kiro reads markdown files from a .kiro/steering/ directory, Claude Code uses CLAUDE.md , Cursor uses .cursorrules , and GitHub Copilot uses .github/copilot-instructions.md —but the function is the same: persistent instructions that shape how the model approaches work in your repository. Applied to security analysis, a steering file encodes your team’s triage methodology as machine-executable instructions. Instead of relying on individual engineers to apply that methodology consistently, you encode it once and the model applies it uniformly across analyses. The steering file we’re releasing encodes the architectural principles from the harness post as operational instructions. Where the harness post says apply infrastructure-aware assessment , the steering file specifies exactly how: which controls map to which multipliers, how multipliers stack, and what floor prevents over-confidence in any single control. Why configuration outperforms prompting A single-turn prompt ( find vulnerabilities in this code ) produces whatever the model’s default behavior generates. That default is optimized for helpfulness, not rigor. The model will find things to report because you asked it to find things. A steering file changes the default. It establishes: What counts as evidence: Without explicit instructions, a model treats its own reasoning as sufficient evidence. The steering file requires structural verification—confirmed dataflow, confirmed function existence, and confirmed call path—before a finding is reported. What confidence means: On its own, a model assigns confidence based on how plausible its narrative sounds to itself. The steering file replaces self-reported confidence with a formula computed from binary structural signals. Either taint analysis confirms the flow or it doesn’t. Either a call graph connects entry point to sink or it doesn’t. How infrastructure affects priority: Left to its defaults, a model assesses vulnerabilities in isolation from their deployment context. The steering file requires parsing infrastructure as code (IaC) and applying control-specific multipliers before assigning priority. The goal is reproducibility: the same codebase should produce the same assessed findings regardless of who runs the analysis or when. Consistency is the point. The five sections that matter The full steering file is available in the companion repository. In this section, we explain the design decisions behind its five critical sections. Structural verification over LLM trust Never trust an LLM's self-reported confidence about a vulnerability. Verify claims against the code structure: 1. Do referenced files exist? 2. Do referenced functions exist? 3. Does dataflow confirm the claim? 4. Is there a call path? If a finding fails all structural checks, reject it regardless of how convincing the narrative sounds. This is the single most important instruction in the file. Without it, the model generates plausible-sounding attack chains that reference functions that were renamed three commits ago, files that exist in a different package, or dataflows that pass through sanitization that the model failed to notice. We found that approximately 30% of unsteered model findings referenced code structures that didn’t exist in the target repository. Not wrong interpretations—entirely fabricated paths. The instruction to verify before reporting produced zero fabricated paths in our testing. The key insight: hallucination in security analysis isn’t a minor annoyance. One hallucinated finding that reaches a developer destroys the can quickly erode the credibility of your entire pipeline. Engineers who encounter a fabricated vulnerability are less likely to keep reading the reports. Evidence-based confidence scoring The following formula replaces the model’s intuitive confidence with a score computed from observable signals. Each factor is binary: confirmed or not confirmed. confidence = 0.30 * taint_confirms_flow + 0.25 * no_sanitization_found + 0.20 * entry_point_is_public + 0.15 * call_graph_confirms_path + 0.10 * sink_type_matches_category We weighted taint confirmation highest (0.30) because a confirmed dataflow path—evidence that user-controlled data reaches a security-sensitive operation—is the single strongest predictor that a finding is real. In our validation against known-vulnerable applications, findings with confirmed taint and no sanitization were exploitable 89% of the time. Findings where the model reported HIGH confidence without structural confirmation were exploitable 34% of the time. The formula is a starting point, not a fixed standard. Your weights should reflect your own validation data. Run the formula against a labeled dataset of known true and false positives, then adjust until precision matches your team’s tolerance for noise. Infrastructure-aware assessment This section addresses a common category of over-prioritization: reporting a vulnerability at full severity when compensating controls are already in place. score_after_controls = max(0.15, score * block_1 * block_2 * ... * block_n) Controls are mapped to specific vulnerability classes. An AWS WAF with SQL injection rules in blocking mode is a STRONG control (0.25x multiplier) against SQL injection. It is irrelevant to deserialization attacks. The steering file specifies this mapping explicitly rather than leaving the model to guess. The multiplicative stacking of attack-blocking controls with a floor of 0.15 encodes defense-in-depth thinking. Multiple controls reduce risk more than any single control, but no combination of controls reduces risk to zero. The floor prevents the model from concluding that a vulnerability is completely mitigated and can be ignored. A subtlety we learned through validation: access controls (authentication and authorization) and attack-blocking controls (AWS WAF rules and input validation) serve different functions. Authentication limits who can attempt an exploit. It doesn’t limit what happens when an authenticated user attempts one. A command injection behind AWS Identity and Access Management (IAM) authentication is still a command injection; the attacker pool is smaller, but the impact when exploited is unchanged. The steering file accounts for this by mapping control types to specific score components rather than applying a blanket multiplier. Threat intelligence integration The steering file incorporates signals from the CISA Known Exploited Vulnerabilities (KEV) catalog and the Exploit Prediction Scoring System (EPSS) to boost priority when threat intelligence indicates active risk. The following table lists the primary signals the steering file recognizes and the boost that each signal adds to a finding’s score. Each signal answers a different question about real-world exploitation risk: CISA KEV – Indicates that attackers have exploited the vulnerability in the wild and notes whether it is tied to ransomware campaigns. EPSS – Estimates the probability that attackers will exploit a vulnerability in the next 30 days. Public proof of concept (PoC) – Indicates that working exploit code is already published, so an attacker has little work left to do. Signal Boost Actively exploited (CISA KEV) +0.30 Ransomware-associated (CISA KEV) +0.15 EPSS &gt;= 0.5 +0.20 Public PoC exists +0.10 There’s a cap at +0.50 total boost to prevent threat intelligence from dominating the score. A vulnerability isn’t more technically exploitable because attackers are targeting it, but it is more urgent because the window between theoretically exploitable and actively exploited can be very short. We separate urgency from severity deliberately. A medium-severity dependency vulnerability under active exploitation by ransomware groups demands a faster response than a critical-severity code-level finding that requires complex preconditions and has no known tooling. Priority classification Scoring produces a number and priority classification turns that number into a decision, which is what a developer on the receiving end of a finding needs. The following table shows the four action tiers that the steering file defines. The score and evidence thresholds determine which tier a finding falls into, and each tier prescribes a specific response. The steering file compares these thresholds against the final score: the base score after it applies attack-blocking multipliers and any threat-intelligence boost. That final score is not the confidence value from the formula earlier in this post, and it is not the severity that the scanner reported. Priority Criteria Action P0 Score &gt;= 0.8, no effective attack-blocking mitigation Fix immediately P1 Score &gt;= 0.6 OR active threat intel Fix this sprint P2 Score &gt;= 0.4, partial evidence Investigate when capacity P3 Score &lt; 0.4 or effectively mitigated Accept risk or backlog The most controversial instruction in the file: Do not file P3 findings as security issues. We include it because filing low-confidence or fully mitigated findings as tickets trains teams to ignore security tooling. Each false positive or irrelevant finding filed as a bug reduces engagement with the system’s output. A pipeline that produces ten confirmed findings gets more engineering attention than one that produces two hundred maybes. Validation results We tested the steering file against a purpose-built vulnerable application containing ten known vulnerabilities: eight exploitable and two mitigated by infrastructure controls. The application includes an AWS WAF with SQL injection rules in blocking mode, Amazon Virtual Private Cloud (Amazon VPC) -isolated AWS Lambda functions, and IAM authentication on each endpoint. Without the steering file , the model found all ten vulnerabilities and correctly identified both mitigated findings as lower priority. However, it assigned severity based on intuition ( this is a command injection, so it’s CRITICAL ) rather than evidence, and it produced no structural verification of its claims. With the steering file , the model found nine of ten vulnerabilities (not flagging a hardcoded credential that had been intentionally embedded in unit-testing code and was defined but never called), correctly downgraded the two mitigated findings to P3 with documented rationale, showed its confidence calculation for each finding, and verified each claimed dataflow against the actual code. The scoring calibration required one iteration. Our initial version applied authentication as a blanket multiplier that suppressed all findings behind IAM to P2 regardless of impact. We corrected this by separating access-limiting controls (which reduce the reachability score component) from attack-blocking controls (which reduce the full confidence score). The current version correctly classifies a command injection behind IAM authentication as P0: the auth limits who can reach it, but the impact when exploited is remote code execution regardless. How to use the steering file The three options that follow cover an always-on Kiro steering file, the same content as an on-demand Kiro skill, and how to carry the same content to Claude Code or another assistant. Option 1: As a Kiro steering file Drop the steering file into your repository at .kiro/steering/vuln-triage.md . Any session using Kiro’s built-in default agent loads the instructions automatically. When you or your engineers ask the model to analyze code for security issues, it applies the methodology without additional prompting. If your team uses a custom agent rather than the default, steering files aren’t loaded automatically; you have to add the file to the agent’s resources explicitly: { "resources": ["file://.kiro/steering/**/*.md"] } your-repo/ ├── .kiro/ │ └── steering/ │ └── vuln-triage.md ← steering file ├── src/ ├── cdk/ └── ... You can also place it in ~/.kiro/steering/ to apply the methodology across every workspace on your machine, rather than scoping it to a single repository. Option 2: As a Kiro skill If you want the methodology available on demand rather than consuming context window space in every turn, place it as a skill. Kiro loads only the skill’s name and description at startup and pulls in the full instructions when the skill activates. This keeps the instructions out of unrelated conversations. A skill is a folder containing a SKILL.md file. The folder name must match the name in the YAML front matter: name: vuln-triage description: Structured vulnerability triage methodology with evidence-based scoring and infrastructure-aware prioritization. Use when analyzing code for security vulnerabilities. your-repo/ ├── .kiro/ │ └── skills/ │ └── vuln-triage/ │ └── SKILL.md ← skill file ├── src/ └── ... Kiro’s default agent discovers skills in .kiro/skills/ automatically; no configuration required. The skill then activates either automatically, when Kiro matches a request against the description, or explicitly as a slash command. A skill named vuln-triage becomes /vuln-triage , so an engineer can run an assessment on demand: &gt; /vuln-triage focus on the authentication changes Place skills in ~/.kiro/skills/ to make them available across every project on your machine. If your team uses a custom agent rather than the default, skills aren’t loaded automatically, you must add them to the agent’s resources: { "resources": ["skill://.kiro/skills/*/SKILL.md"] } Option 3: Adapted for other tools The methodology isn’t specific to Kiro. The repository also ships the same content as a CLAUDE.md file for Claude Code, and the principles apply to any assistant that loads persistent instructions from your repository—consult your tool’s documentation for the filename and location it expects. What this doesn’t replace A steering file is methodology, not machinery. It tells the model how to think about findings but doesn’t provide: Programmatic taint tracking: The model approximates dataflow by reading code. A purpose-built taint tracker confirms dataflow against the abstract syntax tree (AST) deterministically. For Python codebases, static analysis tools built on parsers like Tree-Sitter provide this. For other languages, the model’s approximation is reasonable but not authoritative. Live infrastructure verification: The steering file instructs the model to parse IaC files. It can’t make API calls to verify that an AWS WAF rule is attached to the Amazon API Gateway in your deployed environment, or that a security group hasn’t been modified since deployment. Threat intelligence feeds: The file instructs the model to consider CISA Known Exploited Vulnerabilities (KEV) and Exploit Prediction Scoring System (EPSS) data. The model’s training data includes historical KEV entries, but it can’t query live feeds. For current exploitation status, you need an API integration. Execution-based verification: The steering file produces assessed findings. Confirming exploitability by executing a proof of concept against a live environment requires additional tooling: a sandbox, request signing, and differential testing infrastructure. Each of these capabilities adds confidence to the pipeline. The steering file without them still produces measurably better results than an unsteered model: structured findings, cited evidence, and infrastructure-aware prioritization. But it represents the first layer of a mature harness, not the complete system. What comes next The steering file gives your team a structured methodology for AI-powered vulnerability triage today. It works with the tools you already have. It works without infrastructure changes, new services, or a procurement process. The steering file is available in our GitHub repository . We encourage you to use it, adapt it to your environment, and let us know what you find. The authors work on security automation at AWS. The patterns described here emerged from building and validating AI-powered vulnerability detection systems across multiple teams and deployment environments. If you have feedback about this post, leave a comment in the Comments section below. Justin Kontny Justin is a Senior Software Engineer, Security, at AWS who blends a passion for software development with deep expertise in cloud security. He focuses on building agentic security solutions using AI-Driven Development Lifecycle (AIDLC) practices, transforming security from a barrier into a business enabler. Outside of work, Justin enjoys spending time with his children and staying active outdoors. Ievgeniia Ieromenko Ievgeniia is a Software Development Engineer at AWS, where she builds tooling and agentic AI systems designed to strengthen security posture without slowing delivery. Outside of work, she enjoys traveling, volunteering, and outdoor adventures with her very good dog, Pickle. Nidhi Ramakant Nidhi is a Software Development Manager at AWS with two decades of experience in security and enterprise architecture. She’s obsessed with helping customers secure their environments and building creative solutions that make security decisions easier. She’s equally invested in developing the talent around her. Outside work, she’s either binging shows or vibe coding apps for secure local LLMs so her kids can explore and learn safely.

Russian cyberattacks against UK are 'Putin Tax' costing $3.3 billion, says lawmaker The British government is failing to measure what Russian cyberattacks, sabotage and threats to critical infrastructure are costing the country, according to a lawmaker’s report published Wednesday. The report, which gives its own estimate of between £2 billion and £2.5 billion ($2.6 billion to $3.3 billion) a year — a figure described as a floor — is titled The Putin Tax and written by Labour MP Graeme Downie, alongside postdoctoral researcher Dominic Reed. Its authors say their methodology in arriving at that figure was limited, but stressed the principal point was the lack of an official alternative. Ahead of what is expected to be a difficult first budget from Prime Minister Andy Burnham’s new government later this month, the report argues that if the public cannot see what Russian activity costs, it cannot weigh that burden against the cost of defending against it. Downie submitted a series of parliamentary questions to several government departments and found that ministers held no estimates of the economic impact of incidents linked to the Kremlin. No analysis was done of the costs of two ransomware attacks — one on National Health Service software supplier Advanced, and another on Royal Mail — carried out by a group alleged to operate with the Kremlin’s tacit consent and, in some cases, with connections to Russian intelligence. “The costs of flooding are measured or estimated because flood defenses cost money. The costs of fraud are measured because anti-fraud activity costs money. Hostile-state activity increasingly affects critical infrastructure, public services and the wider economy,” the report says. “Yet no equivalent effort has been made to understand its cumulative financial impact.” The report also references the August 2025 cyberattack on Jaguar Land Rover, estimated to have cost the British economy $2.5 billion — although the U.K. government has not formally attributed it to Russia-linked actors — alongside an arson attack in 2024 ordered by Russia’s Wagner Group on a London warehouse. The largest single component of the headline figure was derived by assuming Russia is responsible for 10% of the £14.7 billion ($19.3 billion) the government says cybercrime costs British businesses annually, although this percentage was not based on a precise attribution. The remaining figures, including hostile activity threatening subsea cables, are also from models and not public data. A matter of trust The report’s argument echoes one made by Gen. Sir Jim Hockenhull, the former head of Britain’s Defence Intelligence, in an interview with Recorded Future News earlier this year. Hockenhull said Britain has failed to make the public case for investing in security, in part because the evidence underpinning that case stays classified. “We assume the public understands the connection, but if our insight stays highly classified, in the hands of senior officials and politicians, we’re effectively asking people to trust us without seeing the evidence,” he said. He called for a sustained coalition effort — inside and outside government — to make the threat accessible and understood, warning that repeating “war is possible” without context is an argument that cannot compete with funding for schools or healthcare. One of Downie’s recommendations — a national public awareness campaign on hostile-state threats and cyber resilience — is a direct response to that gap. The report also recommends that the government publish annual economic assessments of hostile foreign-state activity, that the National Cyber Security Centre include cost estimates alongside attribution in its reporting, and that the Ministry of Defence develop a methodology for costing physical hostile activity. “The challenge now is not proving that the Putin Tax exists but ensuring that Britain starts measuring it,” said Downie. A government spokesperson said: "We have been clear that Russia’s continued hybrid attacks are egregious and wholly unacceptable. This government has taken tough action — expelling Russian intelligence officers, sanctioning the GRU, clamping down on illicit finance networks and ensuring Russia's criminal proxies are disrupted and brought to justice." "The UK is steadfast in its support for Ukraine," the spokesperson said, "and we will continue to stand shoulder to shoulder with our allies in the face of Russian aggression." Alexander Martin is the UK Editor for Recorded Future News. He was previously a technology reporter for Sky News and a fellow at the European Cyber Conflict Research Initiative, now Virtual Routes. He can be reached securely using Signal on: AlexanderMartin.79

The Computer Emergency Response Team of Ukraine (CERT-UA) has identified more than 100 compromised websites that have been injected with malicious JavaScript to serve an information-stealing malware called LunexStealer (aka Psychedelic Stealer). The activity, which was observed by the agency in September 2026, has been attributed to a threat cluster dubbed UAC-0277. It did not disclose who the

The patches resolve a critical vulnerability in Android’s System component that could lead to privilege escalation. The post Android’s October 2026 Updates Patch 25 Vulnerabilities appeared first on SecurityWeek .

In cloud-centered environments, establishing trust between workloads is fundamental to securing machine-to-machine communication. Traditional approaches such as API keys, shared secrets, and static service account credentials weren’t designed for the scale and ephemeral nature of cloud workloads. This drives an organizational need to shift from long-term, static credentials to short-lived cryptographic workload identities. Organizations are turning to SPIFFE (Secure Production Identity Framework for Everyone) as a core component of their workload identity strategy. SPIFFE is a set of open source standards for securely identifying software systems in dynamic and heterogeneous environments. Using SPIFFE can help address what’s known as the bottom turtle problem: the circular dependency where protecting one credential requires yet another credential. SPIRE (the SPIFFE Runtime Environment) is an open source implementation of SPIFFE. Customers can use it to quickly experiment with the framework. However, there are operational and security considerations when deploying SPIRE in production, such as: Where cryptographic signing keys for workload identities are managed How to ensure availability and resiliency of the workload identity registry How the SPIRE Certificate Authority integrates into the existing enterprise PKI How workloads without direct connectivity to the SPIRE server validate identities How workload identities are delivered to serverless environments How fine-grained authorization based on SPIFFE IDs is enforced In this post, we show you how to address each of these considerations by offloading SPIRE core functionality to AWS managed services. This post is accompanied by a Github Repository that guides you through the deployment of the reference architecture. To learn the core concepts the SPIFFE framework, take a moment to familiarize yourself with the SPIFFE documentation . SPIRE background A SPIRE deployment is comprised of at least one SPIRE Server, at least one SPIRE Agent, and at least one workload. Figure 1: SPIRE high-level architecture The SPIRE Server is deployed on a central control plane instance (or instances) and manages identity issuance and stores workload identity registrations. The SPIRE server handles five key functions: RegistrationAPI : Create, update, and delete registration entries that define which workloads are entitled to specific SPIFFE IDs based on selectors (for example, Kubernetes namespace, Unix UID). DataStore : The SPIRE server uses a data store to keep track of the workload identity registration entries and the status of the SVIDs it has issued. KeyManager : Controls how the server manages private keys used to sign X.509-SVIDs and JWT-SVIDs. BundlePublisher : Publishes the local trust bundle to a store. The trust bundle is an object containing a trust domain’s cryptographic keys UpstreamAuthority : Dictates which root certificate authority is used to sign the SPIRE certificate authority (CA) certificate The SPIRE Agent is distributed across your workloads, whether they run on Amazon Elastic Compute Cloud (Amazon EC2) instances, Amazon Elastic Container Service (Amazon ECS) containers, or Amazon Elastic Kubernetes Service (Amazon EKS) Pods. The SPIRE Agent handles: WorkloadAPI : Exposes the workload API to workloads, which enable workloads to retrieve their SVIDs and trust bundles from the SPIRE server. NodeAttestation : SPIRE requires that each agent attest and verify itself. WorkloadAttestation : The SPIRE agent collects workload metadata to determine its identity. SVIDStore : The SPIRE Agent also stores SVIDs in other destinations, such as AWS Secrets Manager or HashiCorp Vault making them available for workloads running in serverless environments. After the server and agent are deployed, applications retrieve short-lived SPIFFE Verifiable Identity Documents ( X.509 Certificates or JSON Web Tokens (JWTs) ) using the workload API. How to use AWS managed services for core SPIRE functions In the following sections, we dive deeper into what each of these SPIRE functions does and the advantages of using each AWS service for the function. Figure 2: SPIFFE architecture using AWS managed services To deploy the infrastructure required to follow along with this post, follow the deployment process in the Github Repository . Note : For each managed service, there’s a parameter in the source AWS CloudFormation templates that you can use to specify whether to provision the resource. For example, if you already have an AWS Private Certificate Authority (AWS Private CA) certificate authority deployed in your environment, you can use that for your SPIRE implementation and avoid provisioning a new certificate authority. SPIRE Key Manager using AWS KMS The SPIRE Key Manager controls the cryptographic keys that are used to sign SPIFFE Verifiable Identity Documents (SVIDs), which are either X.509 certificates or JWTs. By using SPIRE, you can configure the cryptographic keys to be either stored in memory or on disk, or to use a plugin where external keys are used for signing SVIDs. By using the AWS KMS plugin for SPIRE , you bring the security benefits of AWS KMS to your SPIRE implementation. HSMs : AWS KMS uses hardware security modules (HSMs) that have been validated under FIPS 140-3 Level 2 Key protection : Your plaintext AWS KMS keys don’t leave the HSMs, aren’t written to disk, and are only used in the volatile memory of the HSMs for the time needed to perform your requested cryptographic operation Comprehensive auditing : Each request to use the keys for signing must be authenticated using Signature Version 4 (SigV4) and is audited and logged in AWS CloudTrail Fine-grained access control: Use AWS KMS Key Policies to restrict access to your signing keys This configuration block indicates to SPIRE that AWS KMS keys are used to sign our SVIDs: KeyManager "aws_kms" { plugin_data { region = "&lt;your-region&gt;" key_identifier_file = "./key_metadata" } } This code block exists in the SPIRE server configuration deployed in the Github repository. SPIRE datastore using Amazon Aurora The SPIRE server uses a data store to keep track of the workload identity registration entries as well as the status of the SVIDs it has issued. By default, the datastore lives as an SQLite database in memory. However, you can configure the SPIRE server to use Amazon Aurora . By doing this, you can decouple the database from the server and offload the operational overhead of managing the datastore to AWS. Benefits: High availability : Automatic failover and multi-Availability Zone deployments Automated backups : Point-in-time recovery and automated backup retention Scalability : Scale compute and storage independently Security : Encryption at rest and in transit, with AWS Identity and Access Management (IAM) Monitoring : Built-in performance insights and enhanced monitoring Reduced operational burden : Automated patching, maintenance, and updates To do this, the CloudFormation stack provisions: An Aurora PostgreSQL Cluster A database user with the capability to authenticate through AWS IAM Network connectivity between your SPIRE Server and the database After the sample finishes deployment, the configuration in the SPIRE server is changed from the default: DataStore "sql" { plugin_data { database_type = "sqlite3" connection_string = "/opt/spire/data/server/datastore.sqlite3" } } To: DataStore "sql" { plugin_data { database_type "aws_postgres" { region = "&lt;region&gt;" } connection_string = "dbname=&lt;dbname&gt; user=spiffe host=&lt;your_db_endpoint&gt; port=&lt;your_port&gt;" } } For more information, see Datastore SQL Plugin . SPIRE certificate authority using AWS Private Certificate Authority The SPIRE Server issues SVIDs to SPIRE agents and workloads. Given that these SVIDs are X.509 certificates, the SPIRE server needs to act as a certificate authority. In the default configuration of SPIRE, the server generates a self-signed certificate that it will use as the root CA certificate. In production scenarios, organizations often use their existing AWS Private CA certificate authority hierarchy. Using the AWS Private CA plugin for SPIRE, you configure the SPIRE CA to act as an issuing certificate authority that chains to your existing root CA. This delivers three benefits for your SPIRE implementation: HSM-backed root of trust : The root of trust of your CA hierarchy is backed by fully managed, FIPS 140-2 Level 3 validated hardware security modules Non-exportable private keys : The private keys for the root CA can’t be exported Fully Managed Certificate Revocation Lists and OCSP endpoint : In case the issuing CA certificate needs to be revoked Note : If the SPIRE CA certificate will be signed by an issuing CA, you need to ensure that the path length of that CA is at least 1. The sample code provisions a root CA, so this isn’t an issue if you’re following the sample code. After the sample deployment is complete, the configuration of the SPIRE server configuration includes the UpstreamAuthority plugin to use your AWS Private CA certificate authority as the root of trust. UpstreamAuthority "aws_pca" { plugin_data { region = "&lt;aws_region&gt;" certificate_authority_arn = "&lt;your_pca_arn&gt;" ca_signing_template_arn = "arn:aws:acm-pca:::template/SubordinateCACertificate_PathLen0/V1" } } For more information, see the AWS Private CA upstream authority plugin documentation . SPIRE bundle publisher using Amazon S3 In SPIFFE, trust bundles are sets of public keys that are used by destination workloads to verify the identity of source workloads. These bundles contain the root certificates and public keys used to sign JWT SVIDs. The SPIRE Server supports exposing an endpoint containing this trust bundle or publishing the bundle to Amazon Simple Storage Service (Amazon S3) . By publishing the bundle to Amazon S3, you can: Decouple : Decouple bundle access from the SPIRE server availability Continuous validation : Allow destination workloads to continually validate source workload identities without requiring network access to the SPIRE server Global distribution : Distribute the trust bundle using Amazon CloudFront , improving performance through the CloudFront global edge network with over 750 Points of Presence Reduced load : Offload trust bundle retrieval traffic from the SPIRE server Version control : Maintain historical versions of trust bundles with S3 versioning The following is a sample configuration for this plugin: BundlePublisher "aws_s3" { plugin_data { region = "&lt;your_bucket_region&gt;" bucket = "&lt;your_bucket_name&gt;" object_key = "&lt;your_bundle_name" format = "spiffe" } } For more information, see S3 Bundle Publisher Plugin Reference . SPIRE Agent SVID store using Secrets Manager In a typical SPIRE implementation, SVIDs are retrieved from the workload API using the SPIRE agent by workloads. In serverless or container cases, it isn’t feasible or possible to run the SPIRE agent, especially in workloads running on AWS Lambda or an AI agent running in Amazon Bedrock AgentCore Runtime . In these scenarios, use the SVID store plugin to push the SVID to Secrets Manager . In this scenario, you still need a SPIRE agent running on a node that performs node attestation with the SPIRE server and delivers the SVID to a secrets store. One of the available secrets store plugins is the AWS Secrets Manager SVIDStore Plugin . Benefits: Encryption at rest : Secrets are encrypted by default using AWS managed or customer-managed AWS KMS keys Broad integration : Integrations with multiple compute types, including AWS Secrets Manager Lambda Extension , Amazon ECS , Amazon EMR , and 52 other AWS services Client-side caching : Secrets Manager provides client-side caching libraries to improve performance and reduce API calls Multi-region replication : Built-in multi-Region replication functionality for workloads with multi-region requirements Fine-grained access control : Use resource policies to control which workloads access which SVIDs Audit trail : All secret access is logged in CloudTrail This plugin is configured in the agent , as opposed to the SPIRE server. A reference for the specific permissions required are in the plugin Github repository . In the sample code, see the configuration in the following agent.conf file: SVIDStore "aws_secretsmanager" { plugin_data { region = "&lt;your_region&gt;" } } When you need to specify a given workload’s SVID to be pushed to Secrets Manager, you add the storeSVID and selector parameters when you create the entry in the workload registry. If you’re managing your SPIRE server in Kubernetes, the appropriate command looks like: kubectl exec -n spire spire-server-&lt;postfix&gt;-- \ /opt/spire/bin/spire-server entry create \ -spiffeID spiffe://example.org/&lt;workload_name&gt; \ -parentID spiffe://example.org/ns/spire/sa/spire-agent \ -selector aws_secretsmanager:secretname:&lt;workload_name&gt; \ -storeSVID Fine-grained access control using Verified Permissions Up to this point, all the managed services we’ve talked about have been used for creating and distributing SVIDs and trust bundles to workloads. However, a key advantage of using a framework such as SPIFFE is that it allows resource owners to protect resources with fine-grained access control. One managed service that helps you do that in the context of SPIFFE and SPIRE implementations is Amazon Verified Permissions . Verified Permissions is a scalable, fine-grained permissions management and authorization service that helps you build secure applications. You can use it to: Define declarative policies : Use Cedar policy language , which provides human-readable, declarative access control rules Centralize policy management : Separate authorization logic from application code Take advantage of the straightforward policy authoring, formal verification capabilities, and performance benefits of Cedar Make real-time decisions : Evaluate authorization requests in real-time based on multiple factors including user identity, workload identity (SPIFFE ID), resource attributes, and contextual information Integrate with identity providers : Support for OpenID Connect (OIDC) providers, enabling validation of JWT tokens including JWT-SVIDs With Verified Permissions, you authenticate SPIRE issued SVIDs using the public keys associated with your trust domain, and deploy fine-grained authorization policies protecting your resources. To use Verified Permissions, you need a policy store, an identity source , and authorization policies . The github sample creates a policy store on your behalf and sets up the necessary infrastructure to have SPIRE serve as an identity source for your policy store. You will need policies to enforce fine grained authorization. The following sample policy forbids a specific workload from taking any action: forbid( principal, action, resource ) when { context has sub &amp;&amp; context.sub like "spiffe://example.org/forbidden-workload/*" }; Or conversely allows a specific workload to take actions: permit( principal, action, resource ) when { context has sub &amp;&amp; context.sub like "spiffe://example.org/allowed-workload/*" }; Experiment with these policies as you build on top of your SPIRE infrastructure. Conclusion This post demonstrates how organizations enhance their SPIRE deployments on AWS by replacing default implementations with AWS managed services. We showed you integrations with AWS KMS for SVID signing, Amazon RDS Aurora for managed datastore operations, AWS Private Certificate Authority for root of trust, Amazon S3 and CloudFront for global trust bundle distribution, AWS Secrets Manager for SVID storage, and Amazon Verified Permissions for fine-grained authorization. By adopting these integrations, organizations can improve security posture, reduce operational complexity, and enhance resiliency. If you’re interested in learning SPIFFE on AWS, check out our SPIRE on AWS github sample or the SPIFFE and SPIRE on AWS Workshop for hands-on learning. If you have feedback about this post, submit comments in the Comments section below. Brendan Paul Brendan is a Security Services SA Manager at AWS and has been at AWS for more than 7 years. He spends most of his time at work helping customers solve problems in the data protection and workload identity domains. Outside of work, he’s pursuing his master’s degree in data science from UC Berkeley. Meg Peddada Meg is a Principal FSI Security Solutions architect specializing in security, risk, and compliance. Her expertise spans governance, security automations, threat management, and architecture. In her spare time, she loves playing volleyball, arts and crafts, and finding new brunch experiences.

Linux backdoors targeting telecom and network appliances in South Korea and Taiwan have been disguising their traffic as email services and seemingly legitimate processes to blend in and evade detection. Threat actors are known to name their malicious software after a legitimate operating system component or a process as a defense evasion measure. By borrowing the name of a real binary, it may

You’re building a data agent that lets business users ask questions about lakehouse data in natural language. You’ve already built governance policies that control who can access which datasets. The challenge is making the agent respect those rules without rebuilding them in your application code. When a user asks a question, the agent maps it to data and constructs a query. The tool runs under its own AWS Identity and Access Management (IAM) role, so AWS Lake Formation sees the tool’s credentials, not the person behind the request. This leaves you with two inadequate options: restrict tool access (limiting self-service analytics) or rebuild access controls in application code (moving governance out of the data layer). In this post, we show you a different approach: identity-aware AI data agents that propagate each user’s identity through every hop, from the user, through the agent, into the tool, so Lake Formation evaluates the user’s grants. Your application code makes no authorization decisions, existing Lake Formation policies work without modifications, and AWS CloudTrail records the actual person who accessed the data. In this post, you learn how to: Set up per-user data access controls for AI agents querying your lakehouse without rewriting your existing Lake Formation governance policies by configuring Amazon Bedrock AgentCore to carry each user’s identity through trusted identity propagation (TIP). Ensure auditability and compliance by performing a server-side token exchange inside AWS Lambda that converts the identity token into Lake Formation credentials scoped to the real user, with CloudTrail recording every query. Validate the pattern end-to-end by testing with multiple users and confirming per-user query results and CloudTrail audit evidence. The building blocks in this post, OAuth 2.0 token delegation, AWS IAM Identity Center , Lake Formation, and Lambda are well-documented individually. The new constraint is that a foundation model (FM) now sits in the middle of the propagation chain. The FM is the agent’s brain, it decides which tools to call and what arguments to pass and anything that enters its context (prompts, tool schemas, arguments) is accessible within that trust boundary. So, the user’s identity token must reach the tool, but it must do so on the HTTP transport layer, bypassing the FM’s reasoning layer entirely. This post demonstrates the three Amazon Bedrock AgentCore configurations that achieve that. Whether you’re building agents on Strands, LangGraph, or a similar framework, this post gives you a deployable pattern on Amazon Bedrock AgentCore. Security engineers will find the identity-transport and audit properties relevant, and data platform owners will see how existing Lake Formation grants extend to AI workloads with no changes. Solution overview Figure 1: Solution overview With this pattern (shown in Figure 1), your data agent can query Lake Formation governed data with per-user access controls, full CloudTrail audit trails, and no changes to your existing governance policies. Here’s how it works. Two tokens travel through the system. An access_token authenticates the request at each trust boundary ( Bedrock AgentCore Runtime , Bedrock AgentCore Gateway ). An id_token carries your identity and is exchanged, server-side, for the identity context that Lake Formation evaluates. A separate TIP role carries only the IAM permissions needed to call service APIs, it has no Lake Formation data grants. Lake Formation evaluates only the propagated user identity, not the TIP role. The request flow is: User to UI: The user authenticates with an OpenID Connect (OIDC) identity provider (IdP). This post uses Amazon Cognito , but you can use any OIDC provider, such as Okta. The UI receives an id_token and an access_token . UI to Bedrock AgentCore Runtime: The UI calls the agent running in AgentCore Runtime over HTTPS. The access_token goes in the standard Authorization header. The id_token goes in a custom header: X-Amzn-Bedrock-AgentCore-Runtime-Custom-IdToken . The HTTP body contains only the user’s prompt. AgentCore Runtime to agent code: The runtime validates the access_token against the configured JSON Web Token (JWT) authorizer, then passes the request to the agent container with both headers accessible through context.request_headers . Agent to Bedrock AgentCore Gateway: The agent opens a Model Context Protocol (MCP) connection to an AgentCore gateway, including both headers on the connection. The AgentCore gateway validates the access_token and forwards the custom header to its Lambda target. AgentCore Gateway to Lambda: The propagated headers arrive in context.client_context.custom[‘bedrockAgentCorePropagatedHeaders’] . Lambda to the data layer: Lambda validates the id_token , exchanges it for an identity context, assumes a role with that context, and runs the Amazon Athena query under the user’s identity. Lake Formation evaluates grants against the real user. Athena returns only the rows and columns that the user is entitled to see. CloudTrail records the assumed role with an onBehalfOf entry identifying the human. Now that you’ve seen the end-to-end flow, the following sections walk through each piece, starting with what you need to have in place before you build. Prerequisites This post assumes you have the working knowledge of OAuth 2.0, IAM, and Lake Formation grants. An IAM Identity Center instance with a trusted token issuer (TTI) configured to accept your OIDC IdP’s tokens. An OAuth Application in IAM Identity Center configured for CreateTokenWithIAM with the JWT Bearer grant. Lake Formation governing your AWS Glue Data Catalog, with grants already assigned to users or groups. An Athena workgroup and an Amazon Simple Storage Service (Amazon S3) bucket for query results. An OIDC IdP. The reference implementation uses Amazon Cognito as the demo IdP, but the pattern is IdP-agnostic. Auth0, Microsoft Entra ID, Okta, Ping, or any OIDC-compliant provider works identically, if your TTI accepts its tokens. This post doesn’t walk through setting up any of these components. The existing AWS documentation covers each one. For more information, see the links in the preceding list and the related resources at the end of this post. The three Bedrock AgentCore configuration steps Three Bedrock AgentCore features make this pattern work. Together they form the chain of custody for the user’s id_token from the moment it arrives at the Bedrock AgentCore Runtime to the moment Lambda uses it. Configure the runtime request header allow list Bedrock AgentCore Runtime doesn’t pass request headers into the agent container by default. You opt in by declaring an allow list, either through agentcore configure or directly in the runtime configuration: # .bedrock_agentcore.yaml request_header_configuration: requestHeaderAllowlist: - Authorization - X-Amzn-Bedrock-AgentCore-Runtime-Custom-IdToken AgentCore Runtime supports two types of forwarded headers: The standard Authorization header for OAuth inbound JWT authentication ( access_token ), and Custom headers prefixed with X-Amzn-Bedrock-AgentCore-Runtime-Custom- The id_token in this pattern uses a custom header. Inside the agent, the allow listed headers arrive as a dictionary object on the request context. The following Python code runs in the agent container: from bedrock_agentcore.runtime import BedrockAgentCoreApp ID_TOKEN_HEADER = "X-Amzn-Bedrock-AgentCore-Runtime-Custom-IdToken" app = BedrockAgentCoreApp() @app.entrypoint def invoke(payload, context): request_headers = getattr(context, "request_headers", None) or {} id_token = "" access_token = "" for key, value in request_headers.items(): if key.lower() == ID_TOKEN_HEADER.lower(): id_token = value elif key.lower() == "authorization": access_token = value.replace("Bearer ", "") # ... build MCP headers and call the Gateway The agent code reads the id_token from the HTTP transport and forwards it (also on the HTTP transport) to the next hop. It doesn’t treat the token as a tool argument and doesn’t inject it into a prompt. Key takeaway: The runtime allow list is the first gate. Without it, the id_token doesn’t reach your agent code. Configure AgentCore Gateway metadata for header propagation An AgentCore Gateway is the Model Context Protocol (MCP) endpoint the agent talks to. When AgentCore Gateway invokes a Lambda target, it doesn’t forward arbitrary request headers by default. You configure which headers to propagate using metadataConfiguration.allowedRequestHeaders on the target: from aws_cdk import aws_bedrockagentcore as agentcore self.gateway_target = agentcore.CfnGatewayTarget( self, "AthenaTarget", name="athena-executor", gateway_identifier=self.gateway.attr_gateway_identifier, target_configuration=agentcore.CfnGatewayTarget.TargetConfigurationProperty( mcp=agentcore.CfnGatewayTarget.McpTargetConfigurationProperty( lambda_=agentcore.CfnGatewayTarget.McpLambdaTargetConfigurationProperty( lambda_arn=lambda_function_arn, tool_schema=... # execute_athena_query ), ), ), metadata_configuration=agentcore.CfnGatewayTarget.MetadataConfigurationProperty( allowed_request_headers=["X-Amzn-Bedrock-AgentCore-Runtime-Custom-IdToken"], ), ... ) Notice that the tool schema doesn’t include an id_token parameter; there’s no token parameter on any tool. The FM doesn’t see, select, or pass an id_token because the token isn’t part of the tool’s contract. It travels parallel to the tool call, on the HTTP connection, through metadataConfiguration . This is a critical property for security. If you put the id_token in the tool schema instead, the FM becomes responsible for passing it, which means the token lands in prompts, traces, memory, and logs. Keeping the token off the tool contract keeps it out of the FM entirely. Key takeaway: The metadataConfiguration of the AgentCore gateway is the second gate. It controls which headers cross from the agent into the Lambda function without touching the tool schema. Read propagated headers in Lambda On the Lambda side, the propagated header arrives not in the event body but in the client context, under a specific key. The following Python code runs in the Lambda function: ID_TOKEN_HEADER = "X-Amzn-Bedrock-AgentCore-Runtime-Custom-IdToken" def lambda_handler(event, context): client_ctx = getattr(context.client_context, "custom", {}) or {} propagated_headers = client_ctx.get("bedrockAgentCorePropagatedHeaders", {}) id_token = propagated_headers.get(ID_TOKEN_HEADER) if not id_token: return {"statusCode": 400, "body": {"error": "missing id_token"}} # Tool arguments from the agent's call (no id_token here) query = event["query"] database = event["database"] workgroup = event["workgroup"] output_location = event["output_location"] # ... validate token, exchange, run query The event dictionary contains the tool’s declared parameters and nothing else. You reach the id_token only through context.client_context.custom[‘bedrockAgentCorePropagatedHeaders’] . That’s the handoff point. Key takeaway: The id_token arrives through the client context rather than tool arguments; the FM has no access to it. The Lambda is the only component that reads the token. Perform the server-side token exchange After Lambda has the id_token , it validates the token and exchanges it for an identityContext . This step uses standard IAM Identity Center TIP mechanics. That it happens inside Lambda rather than anywhere else is what keeps the identity context from crossing a process boundary. import boto3, jwt, time def exchange_and_assume(id_token: str, user_sub: str): # 1. Validate id_token against the OIDC IdP's JWKS. claims = validate_id_token(id_token) # signature, exp, aud, iss, token_use # 2. Exchange for an Identity Center identityContext. sso_oidc = boto3.client("sso-oidc") resp = sso_oidc.create_token_with_iam( clientId=OAUTH_APPLICATION_ARN, grantType="urn:ietf:params:oauth:grant-type:jwt-bearer", assertion=id_token, ) identity_context = resp["awsAdditionalDetails"]["identityContext"] # 3. AssumeRole with ProvidedContexts sts = boto3.client("sts") assumed = sts.assume_role( RoleArn=TIP_ROLE_ARN, RoleSessionName=f"agent-tip-{user_sub[:8]}-{int(time.time())}", ProvidedContexts=[{ "ProviderArn": "arn:aws:iam::aws:contextProvider/IdentityCenter", "ContextAssertion": identity_context, }], ) creds = assumed["Credentials"] return boto3.Session( aws_access_key_id=creds["AccessKeyId"], aws_secret_access_key=creds["SecretAccessKey"], aws_session_token=creds["SessionToken"], ) Two properties come out of this exchange: The identityContext is created and consumed inside a single Lambda invocation. It doesn’t get returned to the agent, the gateway, or the UI. The resulting boto3.Session holds short-lived credentials whose underlying identity assertion is the real user. When the session calls Athena, the query runs with the user’s identity propagated. Lake Formation sees the user, not the Lambda function’s role. Everything after this, including the Athena query and result formatting, is standard boto3. Configure Lake Formation grants You need one grant to the IAM Identity Center user or group. That’s the whole story at the Lake Formation layer. aws lakeformation grant-permissions \ --principal DataLakePrincipalIdentifier=arn:aws:identitystore:::user/&lt;USER_ID&gt; \ --resource '{"Table":{"DatabaseName":"iceberg_db","Name":"trip_details"}}' \ --permissions SELECT This is the grant Lake Formation evaluates at query time. You add column-level and row-level filters to the same user or group the same way. Nothing here is aware of or specific to AI agents. If you already have a Lake Formation grants model for human users, you already have the grants this pattern needs. Understanding the TIP role: The TIP role that Lambda assumes has no Lake Formation data grants. It holds only IAM permissions to call the service APIs: athena:* for query runs, glue:* for catalog reads, lakeformation:GetDataAccess for the query plan handshake, and Amazon S3 access for the Athena output bucket. When Lambda assumes this role with an identityContext attached through ProvidedContexts , Lake Formation evaluates only the propagated user identity against its grants. The role itself is transparent to the authorization decision. In the more common agent runs as a role pattern, the role carries the grants, which is why per-user governance breaks. Here the role carries no grants; it’s a session vehicle, not an authorization subject. Test the pattern end-to-end Two users, same question, different outcomes. User A has SELECT on trip_details . They ask the agent for five records from the table. Figure 2: Five records are requested and returned by the agent User B has no grant on trip_details . They ask the same question. Figure 3: User doesn’t have access to the data No code changed between the two interactions. No parameter was toggled. Lake Formation made the decision based on the propagated identity. The CloudTrail record for the AssumeRole call shows the delegation: { "eventSource": "sts.amazonaws.com", "eventName": "AssumeRole", "requestParameters": { "roleArn": "arn:aws:iam::&lt;ACCOUNT_ID&gt;:role/&lt;TIP_ROLE_NAME&gt;", "roleSessionName": "agent-tip-&lt;user_sub_prefix&gt;-&lt;timestamp&gt;", "providedContexts": [{ "providerArn": "arn:aws:iam::aws:contextProvider/IdentityCenter", "contextAssertion": "&lt;identity-context-assertion&gt;" }] }, "userIdentity": { "type": "AssumedRole", "onBehalfOf": { "userId": "&lt;IDENTITY_STORE_USER_ID&gt;", "identityStoreArn": "arn:aws:identitystore::&lt;ACCOUNT_ID&gt;:identitystore/&lt;ID&gt;" } } } The onBehalfOf block closes the audit loop. Each query the agent runs on a user’s behalf has a CloudTrail record naming that user, with no additional instrumentation in your code. Security properties Four properties follow from this architecture. These are the core value propositions of the identity-aware pattern: The id_token never reaches the foundation model: It travels on HTTP headers at every hop, and Lambda reads it from context.client_context.custom . It’s not a parameter on any tool. The FM has no path to it: not in tool arguments, not in prompts, not in memory, not in traces. The identity context stays inside a single Lambda invocation: It’s derived from the id_token , used immediately in an AssumeRole call, and discarded. It doesn’t go back to the agent, the gateway, or the UI. Authorization decisions live in Lake Formation, against the real user only: The TIP role the Lambda function assumes has no data grants. Lake Formation evaluates the propagated user identity. No code path in the agent, gateway, or Lambda function performs authorization logic. The audit trail requires no extra work: The CloudTrail AssumeRole event with onBehalfOf identifies the human user for every query. You get the same audit fidelity you would have for human users accessing data directly. Deploy the pattern To deploy this pattern, you need to configure four things: An OIDC IdP with a TTI in IAM Identity Center accepting its tokens, and an Identity Center OAuth Application configured for CreateTokenWithIAM . Bedrock AgentCore Runtime running your agent container with requestHeaderAllowlist covering Authorization and your custom id_token header. Bedrock AgentCore Gateway with a Lambda target whose metadataConfiguration.allowedRequestHeaders includes the id_token header. The Lambda target’s tool schema has no id_token parameter. Lambda reading the id_token from context.client_context.custom[‘bedrockAgentCorePropagatedHeaders’] , performing the token exchange through sso-oidc:CreateTokenWithIAM , and calling sts:AssumeRole with ProvidedContexts to get the TIP-bearing session. Conclusion When an AI agent queries a governed lakehouse, the data layer needs to know who’s asking, not which role the agent is running under. This post showed you how to resolve that by treating the agent as an OAuth delegated actor. The user’s token travels alongside the agent’s HTTP transport but doesn’t enter the model’s context, and the token exchange that produces query-time credentials happens server-side inside Lambda, scoped to a single invocation. The three Bedrock AgentCore features that make this composable ( requestHeaderAllowlist on runtime, metadataConfiguration.allowedRequestHeaders on gateway, and bedrockAgentCorePropagatedHeaders on Lambda) are specific to building on Bedrock AgentCore. Everything downstream of Lambda is IAM Identity Center and Lake Formation functionality. If you’re building agents that read governed data, you don’t have to choose between a single over-permissioned service role and per-user code paths. The identity the data layer evaluates can be the real user, the audit trail can name the real user, and the foundation model doesn’t need to know the user’s token exists. The result is a clean separation: the user’s identity travels end-to-end, the model never sees it, and the data layer enforces it exactly as if the user queried directly. Related resources Trusted Identity Propagation with AWS IAM Identity Center AWS Lake Formation User Guide Amazon Bedrock AgentCore Runtime custom headers Amazon Bedrock AgentCore Gateway header propagation RFC 7523 – JWT Bearer Profiles for OAuth 2.0 Amazon Bedrock AgentCore Runtime A2A protocol contract If you have feedback about this post, submit comments in the Comments section below. Thiyagarajan Mani Thiyagarajan is a Sr. Delivery Consultant at AWS. With over 20 years of experience, he architects modern data platforms spanning lakehouses, ingestion pipelines, and generative and agentic AI applications. He specializes in transforming legacy data ecosystems into scalable, cloud-centered architectures that unlock advanced analytics and intelligent automation for customers. Outside work, he enjoys time with family and riding bikes. Mihir Borkar Mihir is a Senior Solutions Architect at AWS, partnering with ISVs to build and scale their platforms. With a decade of experience across data architecture and delivery, his background in enterprise-scale engagements gives him a builder’s perspective, bridging architecture strategy with practical implementation. Outside work, he explores the latest developments in cloud technologies and AI/ML. Philippe Duplessis-Guindon Philippe is a Delivery Consultant at AWS, where he has worked on a wide range of generative AI projects, touching on most aspects from infrastructure and DevOps to software development and AI/ML. After earning his bachelor’s in software engineering and a master’s in computer vision and machine learning from Polytechnique Montréal, he joined AWS to help customers accelerate their generative AI journeys. Umang Khambhalikar Umang is a Senior Consultant at AWS Professional Services, specializing in data and AI. He helps enterprise customers design and implement secure, governed data platforms and agentic AI solutions using services like Amazon Bedrock AgentCore, AWS Lake Formation, and AWS Glue. Umang brings over 19 years of IT consulting experience to solving complex challenges at the intersection of security, data governance, and generative AI.

CERT-UA found fake Cloudflare verification pages that led visitors into a now-familiar ClickFix trap. This time the goal was to infect machines with an infostealer.

It was discovered that the i.MX clock driver in the Linux kernel did not properly handle certain memory allocation failure conditions, leading to a null pointer dereference vulnerability. A local attacker could possibly use this to cause a denial of service (system crash). (CVE-2022-3114) Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system. This update corrects flaws in the following subsystems: - User-space API (UAPI); - ARM32 architecture; - ARM64 architecture; - MIPS architecture; - PowerPC architecture; - RISC-V architecture; - User-Mode Linux (UML); - x86 architecture; - Block layer subsystem; - Cryptographic API; - ACPI drivers; - Android drivers; - Serial ATA and Parallel ATA drivers; - Drivers core; - DRBD Distributed Replicated Block Device drivers; - Rados block device (RBD) driver; - Bluetooth drivers; - Cdrom driver; - Character device driver; - Hardware random number generator core; - TPM device driver; - Data acquisition framework and drivers; - CPU frequency scaling framework; - Hardware crypto device drivers; - DAX dirext access to differentiated memory framework; - DMA engine subsystem; - FireWire subsystem; - Arm Firmware Framework for ARMv8-A(FFA); - ARM SCMI message protocol; - Intel Stratix 10 firmware drivers; - FPGA Framework; - GPIO subsystem; - GPU drivers; - HID subsystem; - Hardware monitoring drivers; - Intel Trace Hub HW tracing drivers; - I2C subsystem; - IIO subsystem; - IIO ADC drivers; - IIO Magnetometer sensors drivers; - InfiniBand drivers; - Input Device core drivers; - Input Device (Miscellaneous) drivers; - Input Device (Mouse) drivers; - IOMMU subsystem; - IRQ chip drivers; - LED subsystem; - Multiple devices driver; - Media drivers; - MemoryStick subsystem; - Multifunction device drivers; - Fastrpc Driver; - MMC subsystem; - MTD block device drivers; - Ethernet bonding driver; - Network drivers; - Mellanox network drivers; - Microsoft Azure Network Adapter (MANA) driver; - Texas Instruments network drivers; - MediaTek network drivers; - NTB driver; - NVDIMM (Non-Volatile Memory Device) drivers; - NVME drivers; - Parport drivers; - PCI subsystem; - Pin controllers subsystem; - Generic PM domains; - System reset/shutdown drivers; - Power supply drivers; - RapidIO drivers; - Voltage and Current Regulator drivers; - Reset controller framework; - S/390 drivers; - SCSI subsystem; - SLIMbus drivers; - SPI subsystem; - Media staging drivers; - Media Oriented Systems Transport (MOST) driver; - NVIDIA Tegra embedded controller (NVEC) staging driver; - Realtek RTL8723BS SDIO drivers; - TCM subsystem; - Trusted Execution Environment drivers; - Thermal drivers; - Thunderbolt and USB4 drivers; - TTY drivers; - USB DSL drivers; - Cadence USB3 driver; - USB Device Class drivers; - ULPI bus; - DesignWare USB2 driver; - DesignWare USB3 driver; - USB Gadget drivers; - USB Host Controller drivers; - USB ChaosKey driver; - Siemens ID Mouse USB driver; - IOWarrior USB driver; - LD Didactic USB driver; - LEGO USB Tower driver; - USS720 USB parallel port adapter driver; - MediaTek USB3 DRD driver; - USB Serial drivers; - USB Type-C support driver; - USB Type-C Port Controller Manager driver; - USB Type-C Connector System Software Interface driver; - USB over IP driver; - vDPA drivers; - VFIO drivers; - Virtio Host (VHOST) subsystem; - Framebuffer layer; - Watchdog drivers; - Xen hypervisor drivers; - AFS file system; - File systems infrastructure; - BTRFS file system; - Ceph distributed file system; - EROFS file system; - exFAT file system; - Ext4 file system; - F2FS file system; - FUSE (File system in Userspace); - HFS file system; - HFS+ file system; - Journaling layer for block devices (JBD2); - Network file system (NFS) client; - Network file system (NFS) server daemon; - NILFS2 file system; - NTFS3 file system; - OCFS2 file system; - OrangeFS file system; - Proc file system; - SMB network file system; - UDF file system; - XFS file system; - Key management; - Software nodes and device properties; - Glob pattern matching library; - KVM subsystem; - Networking core; - Netfilter; - Socket messages infrastructure; - Network sockets; - Memory Management; - Network traffic control; - IPv6 networking; - Bluetooth subsystem; - IP tunnels definitions; - IPv4 networking; - SCTP protocol; - XFRM subsystem; - io_uring subsystem; - IPC subsystem; - Audit subsystem; - BPF subsystem; - Control group (cgroup); - Kernel CPU control infrastructure; - Kernel exit() syscall; - Kernel futex primitives; - Locking primitives; - Scheduler infrastructure; - Signal handling mechanism; - Timer subsystem; - Tracing infrastructure; - Cryptographic library; - Debug objects infrastructure; - Resizable hashtable library; - Memory management; - 6LoWPAN network protocol; - IEEE 802 network protocols; - 9P file system network protocol; - Asynchronous Transfer Mode (ATM) subsystem; - B.A.T.M.A.N. meshing protocol; - Ethernet bridge; - CAN network layer; - Ceph Core library; - Ethtool driver; - HSR network protocol; - IEEE802154.4 network protocol; - IFE protocol; - IUCV driver; - KCM (Kernel Connection Multiplexor) sockets driver; - Logical Link layer; - MAC80211 subsystem; - IEEE 802.15.4 subsystem; - Management Component Transport Protocol (MCTP); - MultiProtocol Label Switching driver; - Multipath TCP; - NCSI (Network Controller Sideband Interface) driver; - NetLabel subsystem; - NFC subsystem; - Open vSwitch; - Packet sockets; - Phonet protocol; - Packet sampling (psample); - Qualcomm IPC Router (QRTR); - RDS protocol; - SMC sockets; - Sun RPC protocol; - TIPC protocol; - TLS protocol; - Unix domain sockets; - VMware vSockets driver; - Wireless networking; - X.25 network layer; - AppArmor security module; - Integrity Measurement Architecture(IMA) framework; - Apple Onboard Audio ALSA driver; - ALSA framework; - Generic PCM loopback sound driver; - FireWire sound drivers; - ESS Solo-1 ALSA driver; - HD-audio driver; - Simple audio multiplexer codec driver; - SoC Audio for Freescale CPUs drivers; - NVIDIA Tegra ASoC drivers; - USB sound devices; - Perf tools; (CVE-2023-54125, CVE-2023-54271, CVE-2025-22026, CVE-2025-23131, CVE-2025-39863, CVE-2025-39929, CVE-2025-39931, CVE-2026-23364, CVE-2026-31449, CVE-2026-31451, CVE-2026-31610, CVE-2026-31700, CVE-2026-31708, CVE-2026-31709, CVE-2026-31711, CVE-2026-31712, CVE-2026-31715, CVE-2026-43064, CVE-2026-43216, CVE-2026-43219, CVE-2026-43350, CVE-2026-43355, CVE-2026-43491, CVE-2026-43492, CVE-2026-45850, CVE-2026-45930, CVE-2026-45991, CVE-2026-45999, CVE-2026-46003, CVE-2026-46021, CVE-2026-46026, CVE-2026-46038, CVE-2026-46052, CVE-2026-46056, CVE-2026-46065, CVE-2026-46069, CVE-2026-46078, CVE-2026-46086, CVE-2026-46090, CVE-2026-46091, CVE-2026-46092, CVE-2026-46103, CVE-2026-46116, CVE-2026-46159, CVE-2026-46160, CVE-2026-46169, CVE-2026-46180, CVE-2026-46191, CVE-2026-46193, CVE-2026-46196, CVE-2026-46208, CVE-2026-46252, CVE-2026-46291, CVE-2026-46292, CVE-2026-46299, CVE-2026-46320, CVE-2026-46321, CVE-2026-46322, CVE-2026-52909, CVE-2026-52910, CVE-2026-52913, CVE-2026-52917, CVE-2026-52918, CVE-2026-52923, CVE-2026-52927, CVE-2026-52928, CVE-2026-52929, CVE-2026-52930, CVE-2026-52933, CVE-2026-52934, CVE-2026-52935, CVE-2026-52939, CVE-2026-52942, CVE-2026-52943, CVE-2026-52947, CVE-2026-52948, CVE-2026-52977, CVE-2026-53080, CVE-2026-53090, CVE-2026-53133, CVE-2026-53134, CVE-2026-53135, CVE-2026-53136, CVE-2026-53137, CVE-2026-53138, CVE-2026-53139, CVE-2026-53146, CVE-2026-53148, CVE-2026-53149, CVE-2026-53150, CVE-2026-53157, CVE-2026-53158, CVE-2026-53159, CVE-2026-53161, CVE-2026-53163, CVE-2026-53167, CVE-2026-53168, CVE-2026-53177, CVE-2026-53181, CVE-2026-53189, CVE-2026-53194, CVE-2026-53195, CVE-2026-53196, CVE-2026-53199, CVE-2026-53208, CVE-2026-53213, CVE-2026-53217, CVE-2026-53218, CVE-2026-53219, CVE-2026-53223, CVE-2026-53227, CVE-2026-53238, CVE-2026-53239, CVE-2026-53245, CVE-2026-53249, CVE-2026-53252, CVE-2026-53253, CVE-2026-53254, CVE-2026-53255, CVE-2026-53256, CVE-2026-53263, CVE-2026-53264, CVE-2026-53265, CVE-2026-53266, CVE-2026-53268, CVE-2026-53269, CVE-2026-53270, CVE-2026-53273, CVE-2026-53275, CVE-2026-53325, CVE-2026-53329, CVE-2026-53331, CVE-2026-53332, CVE-2026-53337, CVE-2026-53339, CVE-2026-53352, CVE-2026-53356, CVE-2026-53357, CVE-2026-53358, CVE-2026-53381, CVE-2026-53382, CVE-2026-53383, CVE-2026-53385, CVE-2026-53388, CVE-2026-53391, CVE-2026-53392, CVE-2026-53393, CVE-2026-53397, CVE-2026-53399, CVE-2026-53400, CVE-2026-53402, CVE-2026-53403, CVE-2026-63794, CVE-2026-63796, CVE-2026-63798, CVE-2026-63801, CVE-2026-63803, CVE-2026-63806, CVE-2026-63807, CVE-2026-63809, CVE-2026-63810, CVE-2026-63814, CVE-2026-63815, CVE-2026-63817, CVE-2026-63818, CVE-2026-63822, CVE-2026-63823, CVE-2026-63824, CVE-2026-63827, CVE-2026-63828, CVE-2026-63829, CVE-2026-63830, CVE-2026-63831, CVE-2026-63833, CVE-2026-63834, CVE-2026-63835, CVE-2026-63836, CVE-2026-63867, CVE-2026-63868, CVE-2026-63870, CVE-2026-63875, CVE-2026-63889, CVE-2026-63890, CVE-2026-63891, CVE-2026-63892, CVE-2026-63893, CVE-2026-63895, CVE-2026-63897, CVE-2026-63898, CVE-2026-63899, CVE-2026-63900, CVE-2026-63901, CVE-2026-63902, CVE-2026-63903, CVE-2026-63904, CVE-2026-63905, CVE-2026-63908, CVE-2026-63913, CVE-2026-63914, CVE-2026-63915, CVE-2026-63916, CVE-2026-63917, CVE-2026-63919, CVE-2026-63920, CVE-2026-63921, CVE-2026-63925, CVE-2026-63926, CVE-2026-63927, CVE-2026-63928, CVE-2026-63930, CVE-2026-63931, CVE-2026-63933, CVE-2026-63934, CVE-2026-63942, CVE-2026-63947, CVE-2026-63948, CVE-2026-63954, CVE-2026-63956, CVE-2026-63957, CVE-2026-63960, CVE-2026-63961, CVE-2026-63964, CVE-2026-63967, CVE-2026-63971, CVE-2026-63975, CVE-2026-63976, CVE-2026-63985, CVE-2026-63990, CVE-2026-63991, CVE-2026-64002, CVE-2026-64004, CVE-2026-64005, CVE-2026-64009, CVE-2026-64010, CVE-2026-64011, CVE-2026-64012, CVE-2026-64014, CVE-2026-64090, CVE-2026-64093, CVE-2026-64094, CVE-2026-64095, CVE-2026-64116, CVE-2026-64118, CVE-2026-64123, CVE-2026-64126, CVE-2026-64137, CVE-2026-64170, CVE-2026-64187, CVE-2026-64188, CVE-2026-64189, CVE-2026-64191, CVE-2026-64206, CVE-2026-64222, CVE-2026-64225, CVE-2026-64234, CVE-2026-64237, CVE-2026-64242, CVE-2026-64243, CVE-2026-64246, CVE-2026-64249, CVE-2026-64266, CVE-2026-64268, CVE-2026-64269, CVE-2026-64271, CVE-2026-64273, CVE-2026-64274, CVE-2026-64275, CVE-2026-64276, CVE-2026-64277, CVE-2026-64279, CVE-2026-64296, CVE-2026-64298, CVE-2026-64299, CVE-2026-64301, CVE-2026-64303, CVE-2026-64304, CVE-2026-64306, CVE-2026-64312, CVE-2026-64313, CVE-2026-64315, CVE-2026-64316, CVE-2026-64317, CVE-2026-64318, CVE-2026-64322, CVE-2026-64323, CVE-2026-64324, CVE-2026-64329, CVE-2026-64330, CVE-2026-64331, CVE-2026-64332, CVE-2026-64333, CVE-2026-64334, CVE-2026-64335, CVE-2026-64336, CVE-2026-64337, CVE-2026-64338, CVE-2026-64340, CVE-2026-64342, CVE-2026-64343, CVE-2026-64344, CVE-2026-64346, CVE-2026-64347, CVE-2026-64350, CVE-2026-64351, CVE-2026-64352, CVE-2026-64355, CVE-2026-64359, CVE-2026-64360, CVE-2026-64361, CVE-2026-64362, CVE-2026-64363, CVE-2026-64364, CVE-2026-64370, CVE-2026-64371, CVE-2026-64372, CVE-2026-64373, CVE-2026-64374, CVE-2026-64375, CVE-2026-64379, CVE-2026-64380, CVE-2026-64381, CVE-2026-64390, CVE-2026-64401, CVE-2026-64403, CVE-2026-64408, CVE-2026-64411, CVE-2026-64412, CVE-2026-64413, CVE-2026-64420, CVE-2026-64422, CVE-2026-64423, CVE-2026-64425, CVE-2026-64428, CVE-2026-64429, CVE-2026-64430, CVE-2026-64432, CVE-2026-64435, CVE-2026-64436, CVE-2026-64438, CVE-2026-64440, CVE-2026-64441, CVE-2026-64442, CVE-2026-64443, CVE-2026-64444, CVE-2026-64445, CVE-2026-64446, CVE-2026-64448, CVE-2026-64450, CVE-2026-64452, CVE-2026-64454, CVE-2026-64455, CVE-2026-64456, CVE-2026-64461, CVE-2026-64462, CVE-2026-64465, CVE-2026-64468, CVE-2026-64469, CVE-2026-64470, CVE-2026-64471, CVE-2026-64475, CVE-2026-64478, CVE-2026-64483, CVE-2026-64484, CVE-2026-64487, CVE-2026-64488, CVE-2026-64494, CVE-2026-64495, CVE-2026-64496, CVE-2026-64497, CVE-2026-64500, CVE-2026-64503, CVE-2026-64504, CVE-2026-64505, CVE-2026-64510, CVE-2026-64512, CVE-2026-64514, CVE-2026-64524, CVE-2026-64527, CVE-2026-64528, CVE-2026-64529, CVE-2026-64530, CVE-2026-64532, CVE-2026-64533, CVE-2026-64534, CVE-2026-64535, CVE-2026-64536, CVE-2026-64537, CVE-2026-64538, CVE-2026-64540, CVE-2026-64541, CVE-2026-64543, CVE-2026-64544, CVE-2026-64545, CVE-2026-64546, CVE-2026-64547, CVE-2026-64548, CVE-2026-64549, CVE-2026-64550, CVE-2026-64551, CVE-2026-64553, CVE-2026-64554, CVE-2026-64560, CVE-2026-64562, CVE-2026-64563, CVE-2026-64564, CVE-2026-64565, CVE-2026-64567, CVE-2026-64569, CVE-2026-64571, CVE-2026-64572, CVE-2026-64573, CVE-2026-64576, CVE-2026-64578, CVE-2026-64579, CVE-2026-64582, CVE-2026-64583, CVE-2026-64584, CVE-2026-64593, CVE-2026-64594, CVE-2026-64599, CVE-2026-64600, CVE-2026-64602, CVE-2026-64604, CVE-2026-68088, CVE-2026-68090, CVE-2026-68091, CVE-2026-68104, CVE-2026-68106, CVE-2026-68111, CVE-2026-68115, CVE-2026-68117, CVE-2026-68121, CVE-2026-68123, CVE-2026-68125, CVE-2026-68127, CVE-2026-68129, CVE-2026-68131, CVE-2026-68135, CVE-2026-68137, CVE-2026-68140, CVE-2026-68141, CVE-2026-68142, CVE-2026-68143, CVE-2026-68144, CVE-2026-68151, CVE-2026-68153, CVE-2026-68154, CVE-2026-68155, CVE-2026-68156, CVE-2026-68157, CVE-2026-68158, CVE-2026-68160, CVE-2026-68175, CVE-2026-68176, CVE-2026-68180, CVE-2026-68182, CVE-2026-68183, CVE-2026-68184, CVE-2026-68186, CVE-2026-68187, CVE-2026-68188, CVE-2026-68190, CVE-2026-68192, CVE-2026-68195, CVE-2026-68196, CVE-2026-68197, CVE-2026-68199, CVE-2026-68204, CVE-2026-68209, CVE-2026-68212, CVE-2026-68213, CVE-2026-68214, CVE-2026-68215, CVE-2026-68216, CVE-2026-68217, CVE-2026-68218, CVE-2026-68222, CVE-2026-68223, CVE-2026-68226, CVE-2026-68227, CVE-2026-68229, CVE-2026-68231, CVE-2026-68234, CVE-2026-68243, CVE-2026-68244, CVE-2026-68248, CVE-2026-68249, CVE-2026-68250, CVE-2026-68284, CVE-2026-68294, CVE-2026-68297, CVE-2026-68299, CVE-2026-68300, CVE-2026-68301, CVE-2026-68304, CVE-2026-68309, CVE-2026-68313, CVE-2026-68315, CVE-2026-68320, CVE-2026-68322, CVE-2026-68324, CVE-2026-68325, CVE-2026-68326, CVE-2026-68327, CVE-2026-68328, CVE-2026-68331, CVE-2026-68333, CVE-2026-68335, CVE-2026-68338, CVE-2026-68340, CVE-2026-68349, CVE-2026-68350, CVE-2026-68351, CVE-2026-68352, CVE-2026-68353, CVE-2026-68354, CVE-2026-68355, CVE-2026-68357, CVE-2026-68360, CVE-2026-68361, CVE-2026-68363, CVE-2026-68365, CVE-2026-68366, CVE-2026-68368, CVE-2026-68369, CVE-2026-68370, CVE-2026-68373, CVE-2026-68376, CVE-2026-68377, CVE-2026-68388, CVE-2026-68395, CVE-2026-68397, CVE-2026-68398, CVE-2026-68402, CVE-2026-68403, CVE-2026-68405, CVE-2026-68406, CVE-2026-68410, CVE-2026-68411, CVE-2026-68413, CVE-2026-68414, CVE-2026-68417, CVE-2026-68422, CVE-2026-68425, CVE-2026-68428, CVE-2026-68430, CVE-2026-68432, CVE-2026-68433, CVE-2026-68444, CVE-2026-68446, CVE-2026-68449, CVE-2026-68450, CVE-2026-68451, CVE-2026-68452, CVE-2026-68456, CVE-2026-68459, CVE-2026-68460, CVE-2026-68461, CVE-2026-68466, CVE-2026-68467, CVE-2026-68469, CVE-2026-68474, CVE-2026-68475, CVE-2026-68477, CVE-2026-68478, CVE-2026-68479, CVE-2026-68480, CVE-2026-72004, CVE-2026-72005, CVE-2026-72010, CVE-2026-72013, CVE-2026-72014, CVE-2026-72019, CVE-2026-72020, CVE-2026-72021, CVE-2026-72022, CVE-2026-72024, CVE-2026-72025, CVE-2026-72033, CVE-2026-72036, CVE-2026-72038, CVE-2026-72039, CVE-2026-72047, CVE-2026-72048, CVE-2026-72049, CVE-2026-72052, CVE-2026-72054, CVE-2026-72055, CVE-2026-72056, CVE-2026-72061, CVE-2026-72066, CVE-2026-72067, CVE-2026-72068, CVE-2026-72074, CVE-2026-72076, CVE-2026-72078, CVE-2026-72079, CVE-2026-72081, CVE-2026-72082, CVE-2026-72083, CVE-2026-72084, CVE-2026-72085, CVE-2026-72086, CVE-2026-72088, CVE-2026-72102, CVE-2026-72105, CVE-2026-72107, CVE-2026-72108, CVE-2026-72109, CVE-2026-72113, CVE-2026-72114, CVE-2026-72115, CVE-2026-72116, CVE-2026-72117, CVE-2026-72118, CVE-2026-72119, CVE-2026-72120, CVE-2026-72121, CVE-2026-72122, CVE-2026-72123, CVE-2026-72124, CVE-2026-72125, CVE-2026-72126, CVE-2026-72129, CVE-2026-72133, CVE-2026-72135, CVE-2026-72136, CVE-2026-72138, CVE-2026-72140, CVE-2026-72146, CVE-2026-72153, CVE-2026-72159, CVE-2026-72160, CVE-2026-72163, CVE-2026-72164, CVE-2026-72165, CVE-2026-72166, CVE-2026-72167, CVE-2026-72171, CVE-2026-72181, CVE-2026-72182, CVE-2026-72192, CVE-2026-72193, CVE-2026-72194, CVE-2026-72195, CVE-2026-72197, CVE-2026-72215, CVE-2026-72218, CVE-2026-72219, CVE-2026-72223, CVE-2026-72224, CVE-2026-72225, CVE-2026-72226, CVE-2026-72228, CVE-2026-72229, CVE-2026-72230, CVE-2026-72231, CVE-2026-72232, CVE-2026-72233, CVE-2026-72234, CVE-2026-72235, CVE-2026-72238, CVE-2026-72240, CVE-2026-72241, CVE-2026-72245, CVE-2026-72247, CVE-2026-72250, CVE-2026-72251, CVE-2026-72256, CVE-2026-72264, CVE-2026-72265, CVE-2026-72267, CVE-2026-72268, CVE-2026-72269, CVE-2026-72270, CVE-2026-72271, CVE-2026-72272, CVE-2026-72274, CVE-2026-72275, CVE-2026-72276, CVE-2026-72282, CVE-2026-72289, CVE-2026-72296, CVE-2026-72297, CVE-2026-72298, CVE-2026-72306, CVE-2026-72307, CVE-2026-72310, CVE-2026-72314, CVE-2026-72316, CVE-2026-72319, CVE-2026-72322, CVE-2026-72326, CVE-2026-72339, CVE-2026-72347, CVE-2026-72348, CVE-2026-72349, CVE-2026-72350, CVE-2026-72351, CVE-2026-72371, CVE-2026-72374, CVE-2026-72378, CVE-2026-72389, CVE-2026-72392, CVE-2026-72396, CVE-2026-72400, CVE-2026-72406, CVE-2026-72409, CVE-2026-72414, CVE-2026-72418, CVE-2026-72421, CVE-2026-72422, CVE-2026-72428, CVE-2026-72433, CVE-2026-72435, CVE-2026-72441, CVE-2026-72447, CVE-2026-72448, CVE-2026-72450, CVE-2026-72459, CVE-2026-72460, CVE-2026-72466, CVE-2026-72476, CVE-2026-72479, CVE-2026-72481, CVE-2026-72483, CVE-2026-72484, CVE-2026-72489, CVE-2026-72491, CVE-2026-72492, CVE-2026-72502, CVE-2026-74255, CVE-2026-74256, CVE-2026-74262, CVE-2026-74265, CVE-2026-74267, CVE-2026-74276, CVE-2026-74279, CVE-2026-74280, CVE-2026-74281, CVE-2026-74282, CVE-2026-74283, CVE-2026-74284, CVE-2026-74287, CVE-2026-74288, CVE-2026-74292, CVE-2026-74293, CVE-2026-74295, CVE-2026-74297, CVE-2026-74305, CVE-2026-74312, CVE-2026-74313, CVE-2026-74320, CVE-2026-74321, CVE-2026-74327, CVE-2026-74329, CVE-2026-74330, CVE-2026-74331, CVE-2026-74339, CVE-2026-74340, CVE-2026-74346, CVE-2026-74348, CVE-2026-74349, CVE-2026-74351, CVE-2026-74359, CVE-2026-74363, CVE-2026-74376, CVE-2026-74379, CVE-2026-74382, CVE-2026-74384, CVE-2026-74390, CVE-2026-74394, CVE-2026-74395, CVE-2026-74398, CVE-2026-74399, CVE-2026-74402, CVE-2026-74408, CVE-2026-74410, CVE-2026-74416, CVE-2026-74424, CVE-2026-74426, CVE-2026-74427, CVE-2026-74438, CVE-2026-74443, CVE-2026-74444, CVE-2026-74453, CVE-2026-74455, CVE-2026-74456, CVE-2026-74457, CVE-2026-74458, CVE-2026-74459, CVE-2026-74460, CVE-2026-74461, CVE-2026-74463, CVE-2026-74464, CVE-2026-74465, CVE-2026-74467, CVE-2026-74468, CVE-2026-74469, CVE-2026-74471, CVE-2026-74473, CVE-2026-74475, CVE-2026-74478, CVE-2026-74480, CVE-2026-74481, CVE-2026-74482, CVE-2026-74485, CVE-2026-74488, CVE-2026-74490, CVE-2026-74492, CVE-2026-74493, CVE-2026-74495, CVE-2026-74497, CVE-2026-74498, CVE-2026-74499, CVE-2026-74505, CVE-2026-74507, CVE-2026-74508, CVE-2026-74512, CVE-2026-74518, CVE-2026-74519, CVE-2026-74523, CVE-2026-74525, CVE-2026-74540, CVE-2026-74546, CVE-2026-74547, CVE-2026-74548, CVE-2026-74549, CVE-2026-74556, CVE-2026-74557, CVE-2026-74563, CVE-2026-74564, CVE-2026-74566, CVE-2026-74567, CVE-2026-74569, CVE-2026-74577, CVE-2026-74578, CVE-2026-74579, CVE-2026-74580, CVE-2026-74581, CVE-2026-74583, CVE-2026-74584, CVE-2026-74585, CVE-2026-74586, CVE-2026-74587, CVE-2026-74588, CVE-2026-74589, CVE-2026-74597, CVE-2026-74598, CVE-2026-74604, CVE-2026-74609, CVE-2026-74613, CVE-2026-74614, CVE-2026-74615, CVE-2026-74616, CVE-2026-74620, CVE-2026-74622, CVE-2026-74625, CVE-2026-74630, CVE-2026-74635, CVE-2026-74636, CVE-2026-74641, CVE-2026-74648, CVE-2026-74649, CVE-2026-74650, CVE-2026-74651, CVE-2026-74654, CVE-2026-74656, CVE-2026-74657, CVE-2026-74658, CVE-2026-74659, CVE-2026-74660, CVE-2026-74664, CVE-2026-74667, CVE-2026-74669, CVE-2026-74671, CVE-2026-74673, CVE-2026-74675, CVE-2026-74676, CVE-2026-74679, CVE-2026-74680, CVE-2026-74682, CVE-2026-74683, CVE-2026-74688, CVE-2026-74691, CVE-2026-74692, CVE-2026-74693, CVE-2026-74694, CVE-2026-74696, CVE-2026-74697, CVE-2026-74701, CVE-2026-74704, CVE-2026-74705, CVE-2026-74717, CVE-2026-74719, CVE-2026-74720, CVE-2026-74726, CVE-2026-74730, CVE-2026-80591, CVE-2026-80593, CVE-2026-80594, CVE-2026-80595, CVE-2026-80597, CVE-2026-80598, CVE-2026-80599, CVE-2026-80600, CVE-2026-80601, CVE-2026-80603, CVE-2026-80605, CVE-2026-80609, CVE-2026-80613, CVE-2026-80619, CVE-2026-80622, CVE-2026-80626, CVE-2026-80627, CVE-2026-80630, CVE-2026-80644, CVE-2026-80645, CVE-2026-80646, CVE-2026-80647, CVE-2026-80649, CVE-2026-80652, CVE-2026-80659, CVE-2026-80664, CVE-2026-80677, CVE-2026-80679, CVE-2026-80680, CVE-2026-80681, CVE-2026-80706, CVE-2026-80707, CVE-2026-80708, CVE-2026-80714, CVE-2026-80716, CVE-2026-80717, CVE-2026-80718, CVE-2026-80722, CVE-2026-80731, CVE-2026-80732, CVE-2026-80733, CVE-2026-80867, CVE-2026-80875, CVE-2026-80876, CVE-2026-80877, CVE-2026-80879, CVE-2026-80880, CVE-2026-80881, CVE-2026-80886, CVE-2026-80890, CVE-2026-80902, CVE-2026-89774)

It was discovered that the i.MX clock driver in the Linux kernel did not properly handle certain memory allocation failure conditions, leading to a null pointer dereference vulnerability. A local attacker could possibly use this to cause a denial of service (system crash). (CVE-2022-3114) It was discovered that some Arm processors could complete a broadcast translation lookaside buffer (TLB) invalidation before memory writes made through the invalidated translation were globally observed. A local attacker could possibly use this to write to memory after permission to do so had been revoked, bypassing memory protections or escalating privileges. (CVE-2025-10263) Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system. This update corrects flaws in the following subsystems: - ARM64 architecture; - User-space API (UAPI); - ARM32 architecture; - MIPS architecture; - PowerPC architecture; - RISC-V architecture; - User-Mode Linux (UML); - x86 architecture; - Block layer subsystem; - Cryptographic API; - ACPI drivers; - Android drivers; - Serial ATA and Parallel ATA drivers; - Drivers core; - DRBD Distributed Replicated Block Device drivers; - Rados block device (RBD) driver; - Bluetooth drivers; - Cdrom driver; - Character device driver; - Hardware random number generator core; - TPM device driver; - Data acquisition framework and drivers; - CPU frequency scaling framework; - Hardware crypto device drivers; - DAX dirext access to differentiated memory framework; - DMA engine subsystem; - FireWire subsystem; - Arm Firmware Framework for ARMv8-A(FFA); - ARM SCMI message protocol; - Intel Stratix 10 firmware drivers; - FPGA Framework; - GPIO subsystem; - GPU drivers; - HID subsystem; - Hardware monitoring drivers; - Intel Trace Hub HW tracing drivers; - I2C subsystem; - IIO subsystem; - IIO ADC drivers; - IIO Magnetometer sensors drivers; - InfiniBand drivers; - Input Device core drivers; - Input Device (Miscellaneous) drivers; - Input Device (Mouse) drivers; - IOMMU subsystem; - IRQ chip drivers; - LED subsystem; - Multiple devices driver; - Media drivers; - MemoryStick subsystem; - Multifunction device drivers; - Fastrpc Driver; - MMC subsystem; - MTD block device drivers; - Ethernet bonding driver; - Network drivers; - Mellanox network drivers; - Microsoft Azure Network Adapter (MANA) driver; - Texas Instruments network drivers; - MediaTek network drivers; - NTB driver; - NVDIMM (Non-Volatile Memory Device) drivers; - NVME drivers; - Parport drivers; - PCI subsystem; - Pin controllers subsystem; - Generic PM domains; - System reset/shutdown drivers; - Power supply drivers; - RapidIO drivers; - Voltage and Current Regulator drivers; - Reset controller framework; - S/390 drivers; - SCSI subsystem; - SLIMbus drivers; - SPI subsystem; - Media staging drivers; - Media Oriented Systems Transport (MOST) driver; - NVIDIA Tegra embedded controller (NVEC) staging driver; - Realtek RTL8723BS SDIO drivers; - TCM subsystem; - Trusted Execution Environment drivers; - Thermal drivers; - Thunderbolt and USB4 drivers; - TTY drivers; - USB DSL drivers; - Cadence USB3 driver; - USB Device Class drivers; - ULPI bus; - DesignWare USB2 driver; - DesignWare USB3 driver; - USB Gadget drivers; - USB Host Controller drivers; - USB ChaosKey driver; - Siemens ID Mouse USB driver; - IOWarrior USB driver; - LD Didactic USB driver; - LEGO USB Tower driver; - USS720 USB parallel port adapter driver; - MediaTek USB3 DRD driver; - USB Serial drivers; - USB Type-C support driver; - USB Type-C Port Controller Manager driver; - USB Type-C Connector System Software Interface driver; - USB over IP driver; - vDPA drivers; - VFIO drivers; - Virtio Host (VHOST) subsystem; - Framebuffer layer; - Watchdog drivers; - Xen hypervisor drivers; - AFS file system; - File systems infrastructure; - BTRFS file system; - Ceph distributed file system; - EROFS file system; - exFAT file system; - Ext4 file system; - F2FS file system; - FUSE (File system in Userspace); - HFS file system; - HFS+ file system; - Journaling layer for block devices (JBD2); - Network file system (NFS) client; - Network file system (NFS) server daemon; - NILFS2 file system; - NTFS3 file system; - OCFS2 file system; - OrangeFS file system; - Proc file system; - SMB network file system; - UDF file system; - XFS file system; - Key management; - Software nodes and device properties; - Glob pattern matching library; - KVM subsystem; - Networking core; - Netfilter; - Socket messages infrastructure; - Network sockets; - Memory Management; - Network traffic control; - IPv6 networking; - Bluetooth subsystem; - IP tunnels definitions; - IPv4 networking; - SCTP protocol; - XFRM subsystem; - io_uring subsystem; - IPC subsystem; - Audit subsystem; - BPF subsystem; - Control group (cgroup); - Kernel CPU control infrastructure; - Kernel exit() syscall; - Kernel futex primitives; - Locking primitives; - Scheduler infrastructure; - Signal handling mechanism; - Timer subsystem; - Tracing infrastructure; - Cryptographic library; - Debug objects infrastructure; - Resizable hashtable library; - Memory management; - 6LoWPAN network protocol; - IEEE 802 network protocols; - 9P file system network protocol; - Asynchronous Transfer Mode (ATM) subsystem; - B.A.T.M.A.N. meshing protocol; - Ethernet bridge; - CAN network layer; - Ceph Core library; - Ethtool driver; - HSR network protocol; - IEEE802154.4 network protocol; - IFE protocol; - IUCV driver; - KCM (Kernel Connection Multiplexor) sockets driver; - Logical Link layer; - MAC80211 subsystem; - IEEE 802.15.4 subsystem; - Management Component Transport Protocol (MCTP); - MultiProtocol Label Switching driver; - Multipath TCP; - NCSI (Network Controller Sideband Interface) driver; - NetLabel subsystem; - NFC subsystem; - Open vSwitch; - Packet sockets; - Phonet protocol; - Packet sampling (psample); - Qualcomm IPC Router (QRTR); - RDS protocol; - SMC sockets; - Sun RPC protocol; - TIPC protocol; - TLS protocol; - Unix domain sockets; - VMware vSockets driver; - Wireless networking; - X.25 network layer; - AppArmor security module; - Integrity Measurement Architecture(IMA) framework; - Apple Onboard Audio ALSA driver; - ALSA framework; - Generic PCM loopback sound driver; - FireWire sound drivers; - ESS Solo-1 ALSA driver; - HD-audio driver; - Simple audio multiplexer codec driver; - SoC Audio for Freescale CPUs drivers; - NVIDIA Tegra ASoC drivers; - USB sound devices; - Perf tools; (CVE-2023-54125, CVE-2023-54271, CVE-2025-22026, CVE-2025-23131, CVE-2025-39863, CVE-2025-39929, CVE-2025-39931, CVE-2026-23364, CVE-2026-31449, CVE-2026-31451, CVE-2026-31610, CVE-2026-31700, CVE-2026-31708, CVE-2026-31709, CVE-2026-31711, CVE-2026-31712, CVE-2026-31715, CVE-2026-43064, CVE-2026-43216, CVE-2026-43219, CVE-2026-43350, CVE-2026-43355, CVE-2026-43491, CVE-2026-43492, CVE-2026-45850, CVE-2026-45930, CVE-2026-45991, CVE-2026-45999, CVE-2026-46003, CVE-2026-46021, CVE-2026-46026, CVE-2026-46038, CVE-2026-46052, CVE-2026-46056, CVE-2026-46065, CVE-2026-46069, CVE-2026-46078, CVE-2026-46086, CVE-2026-46090, CVE-2026-46091, CVE-2026-46092, CVE-2026-46103, CVE-2026-46116, CVE-2026-46159, CVE-2026-46160, CVE-2026-46169, CVE-2026-46180, CVE-2026-46191, CVE-2026-46193, CVE-2026-46196, CVE-2026-46208, CVE-2026-46252, CVE-2026-46291, CVE-2026-46292, CVE-2026-46299, CVE-2026-46320, CVE-2026-46321, CVE-2026-46322, CVE-2026-52909, CVE-2026-52910, CVE-2026-52913, CVE-2026-52917, CVE-2026-52918, CVE-2026-52923, CVE-2026-52927, CVE-2026-52928, CVE-2026-52929, CVE-2026-52930, CVE-2026-52933, CVE-2026-52934, CVE-2026-52935, CVE-2026-52939, CVE-2026-52942, CVE-2026-52943, CVE-2026-52947, CVE-2026-52948, CVE-2026-52977, CVE-2026-53080, CVE-2026-53090, CVE-2026-53131, CVE-2026-53133, CVE-2026-53134, CVE-2026-53135, CVE-2026-53136, CVE-2026-53137, CVE-2026-53138, CVE-2026-53139, CVE-2026-53146, CVE-2026-53148, CVE-2026-53149, CVE-2026-53150, CVE-2026-53157, CVE-2026-53158, CVE-2026-53159, CVE-2026-53161, CVE-2026-53163, CVE-2026-53167, CVE-2026-53168, CVE-2026-53177, CVE-2026-53181, CVE-2026-53186, CVE-2026-53189, CVE-2026-53194, CVE-2026-53195, CVE-2026-53196, CVE-2026-53199, CVE-2026-53208, CVE-2026-53213, CVE-2026-53216, CVE-2026-53217, CVE-2026-53218, CVE-2026-53219, CVE-2026-53221, CVE-2026-53223, CVE-2026-53227, CVE-2026-53238, CVE-2026-53239, CVE-2026-53245, CVE-2026-53249, CVE-2026-53252, CVE-2026-53253, CVE-2026-53254, CVE-2026-53255, CVE-2026-53256, CVE-2026-53263, CVE-2026-53264, CVE-2026-53265, CVE-2026-53266, CVE-2026-53268, CVE-2026-53269, CVE-2026-53270, CVE-2026-53273, CVE-2026-53275, CVE-2026-53325, CVE-2026-53329, CVE-2026-53331, CVE-2026-53332, CVE-2026-53337, CVE-2026-53339, CVE-2026-53352, CVE-2026-53354, CVE-2026-53355, CVE-2026-53356, CVE-2026-53357, CVE-2026-53358, CVE-2026-53381, CVE-2026-53382, CVE-2026-53383, CVE-2026-53385, CVE-2026-53388, CVE-2026-53391, CVE-2026-53392, CVE-2026-53393, CVE-2026-53397, CVE-2026-53398, CVE-2026-53399, CVE-2026-53400, CVE-2026-53402, CVE-2026-53403, CVE-2026-63794, CVE-2026-63796, CVE-2026-63798, CVE-2026-63800, CVE-2026-63801, CVE-2026-63803, CVE-2026-63806, CVE-2026-63807, CVE-2026-63808, CVE-2026-63809, CVE-2026-63810, CVE-2026-63814, CVE-2026-63815, CVE-2026-63817, CVE-2026-63818, CVE-2026-63822, CVE-2026-63823, CVE-2026-63824, CVE-2026-63827, CVE-2026-63828, CVE-2026-63829, CVE-2026-63830, CVE-2026-63831, CVE-2026-63833, CVE-2026-63834, CVE-2026-63835, CVE-2026-63836, CVE-2026-63867, CVE-2026-63868, CVE-2026-63870, CVE-2026-63875, CVE-2026-63887, CVE-2026-63888, CVE-2026-63889, CVE-2026-63890, CVE-2026-63891, CVE-2026-63892, CVE-2026-63893, CVE-2026-63895, CVE-2026-63897, CVE-2026-63898, CVE-2026-63899, CVE-2026-63900, CVE-2026-63901, CVE-2026-63902, CVE-2026-63903, CVE-2026-63904, CVE-2026-63905, CVE-2026-63908, CVE-2026-63912, CVE-2026-63913, CVE-2026-63914, CVE-2026-63915, CVE-2026-63916, CVE-2026-63917, CVE-2026-63919, CVE-2026-63920, CVE-2026-63921, CVE-2026-63922, CVE-2026-63924, CVE-2026-63925, CVE-2026-63926, CVE-2026-63927, CVE-2026-63928, CVE-2026-63930, CVE-2026-63931, CVE-2026-63933, CVE-2026-63934, CVE-2026-63942, CVE-2026-63947, CVE-2026-63948, CVE-2026-63954, CVE-2026-63956, CVE-2026-63957, CVE-2026-63960, CVE-2026-63961, CVE-2026-63964, CVE-2026-63967, CVE-2026-63971, CVE-2026-63975, CVE-2026-63976, CVE-2026-63984, CVE-2026-63985, CVE-2026-63990, CVE-2026-63991, CVE-2026-63992, CVE-2026-63993, CVE-2026-63994, CVE-2026-64002, CVE-2026-64004, CVE-2026-64005, CVE-2026-64007, CVE-2026-64009, CVE-2026-64010, CVE-2026-64011, CVE-2026-64012, CVE-2026-64014, CVE-2026-64090, CVE-2026-64091, CVE-2026-64093, CVE-2026-64094, CVE-2026-64095, CVE-2026-64116, CVE-2026-64118, CVE-2026-64123, CVE-2026-64126, CVE-2026-64137, CVE-2026-64170, CVE-2026-64187, CVE-2026-64188, CVE-2026-64189, CVE-2026-64191, CVE-2026-64206, CVE-2026-64222, CVE-2026-64225, CVE-2026-64234, CVE-2026-64237, CVE-2026-64242, CVE-2026-64243, CVE-2026-64246, CVE-2026-64249, CVE-2026-64266, CVE-2026-64268, CVE-2026-64269, CVE-2026-64271, CVE-2026-64273, CVE-2026-64274, CVE-2026-64275, CVE-2026-64276, CVE-2026-64277, CVE-2026-64279, CVE-2026-64296, CVE-2026-64298, CVE-2026-64299, CVE-2026-64301, CVE-2026-64303, CVE-2026-64304, CVE-2026-64306, CVE-2026-64312, CVE-2026-64313, CVE-2026-64315, CVE-2026-64316, CVE-2026-64317, CVE-2026-64318, CVE-2026-64322, CVE-2026-64323, CVE-2026-64324, CVE-2026-64329, CVE-2026-64330, CVE-2026-64331, CVE-2026-64332, CVE-2026-64333, CVE-2026-64334, CVE-2026-64335, CVE-2026-64336, CVE-2026-64337, CVE-2026-64338, CVE-2026-64340, CVE-2026-64342, CVE-2026-64343, CVE-2026-64344, CVE-2026-64346, CVE-2026-64347, CVE-2026-64350, CVE-2026-64351, CVE-2026-64352, CVE-2026-64355, CVE-2026-64359, CVE-2026-64360, CVE-2026-64361, CVE-2026-64362, CVE-2026-64363, CVE-2026-64364, CVE-2026-64370, CVE-2026-64371, CVE-2026-64372, CVE-2026-64373, CVE-2026-64374, CVE-2026-64375, CVE-2026-64379, CVE-2026-64380, CVE-2026-64381, CVE-2026-64390, CVE-2026-64401, CVE-2026-64403, CVE-2026-64408, CVE-2026-64411, CVE-2026-64412, CVE-2026-64413, CVE-2026-64420, CVE-2026-64422, CVE-2026-64423, CVE-2026-64425, CVE-2026-64428, CVE-2026-64429, CVE-2026-64430, CVE-2026-64432, CVE-2026-64435, CVE-2026-64436, CVE-2026-64438, CVE-2026-64440, CVE-2026-64441, CVE-2026-64442, CVE-2026-64443, CVE-2026-64444, CVE-2026-64445, CVE-2026-64446, CVE-2026-64448, CVE-2026-64450, CVE-2026-64452, CVE-2026-64454, CVE-2026-64455, CVE-2026-64456, CVE-2026-64461, CVE-2026-64462, CVE-2026-64465, CVE-2026-64468, CVE-2026-64469, CVE-2026-64470, CVE-2026-64471, CVE-2026-64475, CVE-2026-64478, CVE-2026-64483, CVE-2026-64484, CVE-2026-64487, CVE-2026-64488, CVE-2026-64494, CVE-2026-64495, CVE-2026-64496, CVE-2026-64497, CVE-2026-64500, CVE-2026-64503, CVE-2026-64504, CVE-2026-64505, CVE-2026-64510, CVE-2026-64512, CVE-2026-64514, CVE-2026-64524, CVE-2026-64527, CVE-2026-64528, CVE-2026-64529, CVE-2026-64530, CVE-2026-64532, CVE-2026-64533, CVE-2026-64534, CVE-2026-64535, CVE-2026-64536, CVE-2026-64537, CVE-2026-64538, CVE-2026-64540, CVE-2026-64541, CVE-2026-64543, CVE-2026-64544, CVE-2026-64545, CVE-2026-64546, CVE-2026-64547, CVE-2026-64548, CVE-2026-64549, CVE-2026-64550, CVE-2026-64551, CVE-2026-64553, CVE-2026-64554, CVE-2026-64560, CVE-2026-64562, CVE-2026-64563, CVE-2026-64564, CVE-2026-64565, CVE-2026-64567, CVE-2026-64569, CVE-2026-64571, CVE-2026-64572, CVE-2026-64573, CVE-2026-64576, CVE-2026-64578, CVE-2026-64579, CVE-2026-64582, CVE-2026-64583, CVE-2026-64584, CVE-2026-64593, CVE-2026-64594, CVE-2026-64599, CVE-2026-64600, CVE-2026-64602, CVE-2026-64604, CVE-2026-68088, CVE-2026-68090, CVE-2026-68091, CVE-2026-68104, CVE-2026-68106, CVE-2026-68111, CVE-2026-68115, CVE-2026-68117, CVE-2026-68121, CVE-2026-68123, CVE-2026-68125, CVE-2026-68127, CVE-2026-68129, CVE-2026-68131, CVE-2026-68135, CVE-2026-68137, CVE-2026-68140, CVE-2026-68141, CVE-2026-68142, CVE-2026-68143, CVE-2026-68144, CVE-2026-68151, CVE-2026-68153, CVE-2026-68154, CVE-2026-68155, CVE-2026-68156, CVE-2026-68157, CVE-2026-68158, CVE-2026-68160, CVE-2026-68175, CVE-2026-68176, CVE-2026-68180, CVE-2026-68182, CVE-2026-68183, CVE-2026-68184, CVE-2026-68186, CVE-2026-68187, CVE-2026-68188, CVE-2026-68190, CVE-2026-68192, CVE-2026-68195, CVE-2026-68196, CVE-2026-68197, CVE-2026-68199, CVE-2026-68204, CVE-2026-68209, CVE-2026-68212, CVE-2026-68213, CVE-2026-68214, CVE-2026-68215, CVE-2026-68216, CVE-2026-68217, CVE-2026-68218, CVE-2026-68222, CVE-2026-68223, CVE-2026-68226, CVE-2026-68227, CVE-2026-68229, CVE-2026-68231, CVE-2026-68234, CVE-2026-68243, CVE-2026-68244, CVE-2026-68248, CVE-2026-68249, CVE-2026-68250, CVE-2026-68284, CVE-2026-68294, CVE-2026-68297, CVE-2026-68299, CVE-2026-68300, CVE-2026-68301, CVE-2026-68304, CVE-2026-68309, CVE-2026-68313, CVE-2026-68315, CVE-2026-68320, CVE-2026-68322, CVE-2026-68324, CVE-2026-68325, CVE-2026-68326, CVE-2026-68327, CVE-2026-68328, CVE-2026-68331, CVE-2026-68333, CVE-2026-68335, CVE-2026-68338, CVE-2026-68340, CVE-2026-68349, CVE-2026-68350, CVE-2026-68351, CVE-2026-68352, CVE-2026-68353, CVE-2026-68354, CVE-2026-68355, CVE-2026-68357, CVE-2026-68360, CVE-2026-68361, CVE-2026-68363, CVE-2026-68365, CVE-2026-68366, CVE-2026-68368, CVE-2026-68369, CVE-2026-68370, CVE-2026-68373, CVE-2026-68376, CVE-2026-68377, CVE-2026-68388, CVE-2026-68395, CVE-2026-68397, CVE-2026-68398, CVE-2026-68402, CVE-2026-68403, CVE-2026-68405, CVE-2026-68406, CVE-2026-68410, CVE-2026-68411, CVE-2026-68413, CVE-2026-68414, CVE-2026-68417, CVE-2026-68422, CVE-2026-68425, CVE-2026-68428, CVE-2026-68430, CVE-2026-68432, CVE-2026-68433, CVE-2026-68444, CVE-2026-68446, CVE-2026-68449, CVE-2026-68450, CVE-2026-68451, CVE-2026-68452, CVE-2026-68456, CVE-2026-68459, CVE-2026-68460, CVE-2026-68461, CVE-2026-68466, CVE-2026-68467, CVE-2026-68469, CVE-2026-68474, CVE-2026-68475, CVE-2026-68477, CVE-2026-68478, CVE-2026-68479, CVE-2026-68480, CVE-2026-72004, CVE-2026-72005, CVE-2026-72010, CVE-2026-72013, CVE-2026-72014, CVE-2026-72019, CVE-2026-72020, CVE-2026-72021, CVE-2026-72022, CVE-2026-72024, CVE-2026-72025, CVE-2026-72033, CVE-2026-72036, CVE-2026-72038, CVE-2026-72039, CVE-2026-72047, CVE-2026-72048, CVE-2026-72049, CVE-2026-72052, CVE-2026-72054, CVE-2026-72055, CVE-2026-72056, CVE-2026-72061, CVE-2026-72066, CVE-2026-72067, CVE-2026-72068, CVE-2026-72074, CVE-2026-72076, CVE-2026-72078, CVE-2026-72079, CVE-2026-72081, CVE-2026-72082, CVE-2026-72083, CVE-2026-72084, CVE-2026-72085, CVE-2026-72086, CVE-2026-72088, CVE-2026-72102, CVE-2026-72105, CVE-2026-72107, CVE-2026-72108, CVE-2026-72109, CVE-2026-72113, CVE-2026-72114, CVE-2026-72115, CVE-2026-72116, CVE-2026-72117, CVE-2026-72118, CVE-2026-72119, CVE-2026-72120, CVE-2026-72121, CVE-2026-72122, CVE-2026-72123, CVE-2026-72124, CVE-2026-72125, CVE-2026-72126, CVE-2026-72129, CVE-2026-72133, CVE-2026-72135, CVE-2026-72136, CVE-2026-72138, CVE-2026-72140, CVE-2026-72146, CVE-2026-72153, CVE-2026-72159, CVE-2026-72160, CVE-2026-72163, CVE-2026-72164, CVE-2026-72165, CVE-2026-72166, CVE-2026-72167, CVE-2026-72171, CVE-2026-72181, CVE-2026-72182, CVE-2026-72192, CVE-2026-72193, CVE-2026-72194, CVE-2026-72195, CVE-2026-72197, CVE-2026-72215, CVE-2026-72218, CVE-2026-72219, CVE-2026-72223, CVE-2026-72224, CVE-2026-72225, CVE-2026-72226, CVE-2026-72228, CVE-2026-72229, CVE-2026-72230, CVE-2026-72231, CVE-2026-72232, CVE-2026-72233, CVE-2026-72234, CVE-2026-72235, CVE-2026-72238, CVE-2026-72240, CVE-2026-72241, CVE-2026-72245, CVE-2026-72247, CVE-2026-72250, CVE-2026-72251, CVE-2026-72256, CVE-2026-72264, CVE-2026-72265, CVE-2026-72267, CVE-2026-72268, CVE-2026-72269, CVE-2026-72270, CVE-2026-72271, CVE-2026-72272, CVE-2026-72274, CVE-2026-72275, CVE-2026-72276, CVE-2026-72282, CVE-2026-72289, CVE-2026-72296, CVE-2026-72297, CVE-2026-72298, CVE-2026-72306, CVE-2026-72307, CVE-2026-72310, CVE-2026-72314, CVE-2026-72316, CVE-2026-72319, CVE-2026-72322, CVE-2026-72326, CVE-2026-72339, CVE-2026-72347, CVE-2026-72348, CVE-2026-72349, CVE-2026-72350, CVE-2026-72351, CVE-2026-72371, CVE-2026-72374, CVE-2026-72378, CVE-2026-72389, CVE-2026-72392, CVE-2026-72396, CVE-2026-72400, CVE-2026-72406, CVE-2026-72409, CVE-2026-72414, CVE-2026-72418, CVE-2026-72421, CVE-2026-72422, CVE-2026-72428, CVE-2026-72433, CVE-2026-72435, CVE-2026-72441, CVE-2026-72447, CVE-2026-72448, CVE-2026-72450, CVE-2026-72459, CVE-2026-72460, CVE-2026-72466, CVE-2026-72476, CVE-2026-72479, CVE-2026-72481, CVE-2026-72483, CVE-2026-72484, CVE-2026-72489, CVE-2026-72491, CVE-2026-72492, CVE-2026-72502, CVE-2026-74255, CVE-2026-74256, CVE-2026-74262, CVE-2026-74265, CVE-2026-74267, CVE-2026-74276, CVE-2026-74279, CVE-2026-74280, CVE-2026-74281, CVE-2026-74282, CVE-2026-74283, CVE-2026-74284, CVE-2026-74287, CVE-2026-74288, CVE-2026-74292, CVE-2026-74293, CVE-2026-74295, CVE-2026-74297, CVE-2026-74305, CVE-2026-74312, CVE-2026-74313, CVE-2026-74320, CVE-2026-74321, CVE-2026-74327, CVE-2026-74329, CVE-2026-74330, CVE-2026-74331, CVE-2026-74339, CVE-2026-74340, CVE-2026-74346, CVE-2026-74348, CVE-2026-74349, CVE-2026-74351, CVE-2026-74359, CVE-2026-74363, CVE-2026-74376, CVE-2026-74379, CVE-2026-74382, CVE-2026-74384, CVE-2026-74390, CVE-2026-74394, CVE-2026-74395, CVE-2026-74398, CVE-2026-74399, CVE-2026-74402, CVE-2026-74408, CVE-2026-74410, CVE-2026-74416, CVE-2026-74424, CVE-2026-74426, CVE-2026-74427, CVE-2026-74438, CVE-2026-74443, CVE-2026-74444, CVE-2026-74453, CVE-2026-74455, CVE-2026-74456, CVE-2026-74457, CVE-2026-74458, CVE-2026-74459, CVE-2026-74460, CVE-2026-74461, CVE-2026-74463, CVE-2026-74464, CVE-2026-74465, CVE-2026-74467, CVE-2026-74468, CVE-2026-74469, CVE-2026-74471, CVE-2026-74473, CVE-2026-74475, CVE-2026-74478, CVE-2026-74480, CVE-2026-74481, CVE-2026-74482, CVE-2026-74485, CVE-2026-74488, CVE-2026-74490, CVE-2026-74492, CVE-2026-74493, CVE-2026-74495, CVE-2026-74497, CVE-2026-74498, CVE-2026-74499, CVE-2026-74505, CVE-2026-74507, CVE-2026-74508, CVE-2026-74512, CVE-2026-74518, CVE-2026-74519, CVE-2026-74523, CVE-2026-74525, CVE-2026-74540, CVE-2026-74546, CVE-2026-74547, CVE-2026-74548, CVE-2026-74549, CVE-2026-74556, CVE-2026-74557, CVE-2026-74563, CVE-2026-74564, CVE-2026-74566, CVE-2026-74567, CVE-2026-74569, CVE-2026-74577, CVE-2026-74578, CVE-2026-74579, CVE-2026-74580, CVE-2026-74581, CVE-2026-74583, CVE-2026-74584, CVE-2026-74585, CVE-2026-74586, CVE-2026-74587, CVE-2026-74588, CVE-2026-74589, CVE-2026-74597, CVE-2026-74598, CVE-2026-74604, CVE-2026-74609, CVE-2026-74613, CVE-2026-74614, CVE-2026-74615, CVE-2026-74616, CVE-2026-74620, CVE-2026-74622, CVE-2026-74625, CVE-2026-74630, CVE-2026-74635, CVE-2026-74636, CVE-2026-74641, CVE-2026-74648, CVE-2026-74649, CVE-2026-74650, CVE-2026-74651, CVE-2026-74654, CVE-2026-74656, CVE-2026-74657, CVE-2026-74658, CVE-2026-74659, CVE-2026-74660, CVE-2026-74664, CVE-2026-74667, CVE-2026-74669, CVE-2026-74671, CVE-2026-74673, CVE-2026-74675, CVE-2026-74676, CVE-2026-74679, CVE-2026-74680, CVE-2026-74682, CVE-2026-74683, CVE-2026-74688, CVE-2026-74691, CVE-2026-74692, CVE-2026-74693, CVE-2026-74694, CVE-2026-74696, CVE-2026-74697, CVE-2026-74701, CVE-2026-74704, CVE-2026-74705, CVE-2026-74717, CVE-2026-74719, CVE-2026-74720, CVE-2026-74726, CVE-2026-74730, CVE-2026-80591, CVE-2026-80593, CVE-2026-80594, CVE-2026-80595, CVE-2026-80597, CVE-2026-80598, CVE-2026-80599, CVE-2026-80600, CVE-2026-80601, CVE-2026-80603, CVE-2026-80605, CVE-2026-80609, CVE-2026-80613, CVE-2026-80619, CVE-2026-80622, CVE-2026-80626, CVE-2026-80627, CVE-2026-80630, CVE-2026-80644, CVE-2026-80645, CVE-2026-80646, CVE-2026-80647, CVE-2026-80649, CVE-2026-80652, CVE-2026-80659, CVE-2026-80664, CVE-2026-80677, CVE-2026-80679, CVE-2026-80680, CVE-2026-80681, CVE-2026-80706, CVE-2026-80707, CVE-2026-80708, CVE-2026-80714, CVE-2026-80716, CVE-2026-80717, CVE-2026-80718, CVE-2026-80722, CVE-2026-80731, CVE-2026-80732, CVE-2026-80733, CVE-2026-80867, CVE-2026-80875, CVE-2026-80876, CVE-2026-80877, CVE-2026-80879, CVE-2026-80880, CVE-2026-80881, CVE-2026-80886, CVE-2026-80890, CVE-2026-80902, CVE-2026-89774)

It was discovered that the i.MX clock driver in the Linux kernel did not properly handle certain memory allocation failure conditions, leading to a null pointer dereference vulnerability. A local attacker could possibly use this to cause a denial of service (system crash). (CVE-2022-3114) It was discovered that some Arm processors could complete a broadcast translation lookaside buffer (TLB) invalidation before memory writes made through the invalidated translation were globally observed. A local attacker could possibly use this to write to memory after permission to do so had been revoked, bypassing memory protections or escalating privileges. (CVE-2025-10263) Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system. This update corrects flaws in the following subsystems: - ARM64 architecture; - User-space API (UAPI); - ARM32 architecture; - MIPS architecture; - PowerPC architecture; - RISC-V architecture; - User-Mode Linux (UML); - x86 architecture; - Block layer subsystem; - Cryptographic API; - ACPI drivers; - Android drivers; - Serial ATA and Parallel ATA drivers; - Drivers core; - DRBD Distributed Replicated Block Device drivers; - Rados block device (RBD) driver; - Bluetooth drivers; - Cdrom driver; - Character device driver; - Hardware random number generator core; - TPM device driver; - Data acquisition framework and drivers; - CPU frequency scaling framework; - Hardware crypto device drivers; - DAX dirext access to differentiated memory framework; - DMA engine subsystem; - FireWire subsystem; - Arm Firmware Framework for ARMv8-A(FFA); - ARM SCMI message protocol; - Intel Stratix 10 firmware drivers; - FPGA Framework; - GPIO subsystem; - GPU drivers; - HID subsystem; - Hardware monitoring drivers; - Intel Trace Hub HW tracing drivers; - I2C subsystem; - IIO subsystem; - IIO ADC drivers; - IIO Magnetometer sensors drivers; - InfiniBand drivers; - Input Device core drivers; - Input Device (Miscellaneous) drivers; - Input Device (Mouse) drivers; - IOMMU subsystem; - IRQ chip drivers; - LED subsystem; - Multiple devices driver; - Media drivers; - MemoryStick subsystem; - Multifunction device drivers; - Fastrpc Driver; - MMC subsystem; - MTD block device drivers; - Ethernet bonding driver; - Network drivers; - Mellanox network drivers; - Microsoft Azure Network Adapter (MANA) driver; - Texas Instruments network drivers; - MediaTek network drivers; - NTB driver; - NVDIMM (Non-Volatile Memory Device) drivers; - NVME drivers; - Parport drivers; - PCI subsystem; - Pin controllers subsystem; - Generic PM domains; - System reset/shutdown drivers; - Power supply drivers; - RapidIO drivers; - Voltage and Current Regulator drivers; - Reset controller framework; - S/390 drivers; - SCSI subsystem; - SLIMbus drivers; - SPI subsystem; - Media staging drivers; - Media Oriented Systems Transport (MOST) driver; - NVIDIA Tegra embedded controller (NVEC) staging driver; - Realtek RTL8723BS SDIO drivers; - TCM subsystem; - Trusted Execution Environment drivers; - Thermal drivers; - Thunderbolt and USB4 drivers; - TTY drivers; - USB DSL drivers; - Cadence USB3 driver; - USB Device Class drivers; - ULPI bus; - DesignWare USB2 driver; - DesignWare USB3 driver; - USB Gadget drivers; - USB Host Controller drivers; - USB ChaosKey driver; - Siemens ID Mouse USB driver; - IOWarrior USB driver; - LD Didactic USB driver; - LEGO USB Tower driver; - USS720 USB parallel port adapter driver; - MediaTek USB3 DRD driver; - USB Serial drivers; - USB Type-C support driver; - USB Type-C Port Controller Manager driver; - USB Type-C Connector System Software Interface driver; - USB over IP driver; - vDPA drivers; - VFIO drivers; - Virtio Host (VHOST) subsystem; - Framebuffer layer; - Watchdog drivers; - Xen hypervisor drivers; - AFS file system; - File systems infrastructure; - BTRFS file system; - Ceph distributed file system; - EROFS file system; - exFAT file system; - Ext4 file system; - F2FS file system; - FUSE (File system in Userspace); - HFS file system; - HFS+ file system; - Journaling layer for block devices (JBD2); - Network file system (NFS) client; - Network file system (NFS) server daemon; - NILFS2 file system; - NTFS3 file system; - OCFS2 file system; - OrangeFS file system; - Proc file system; - SMB network file system; - UDF file system; - XFS file system; - Key management; - Software nodes and device properties; - Glob pattern matching library; - KVM subsystem; - Networking core; - Netfilter; - Socket messages infrastructure; - Network sockets; - Memory Management; - Network traffic control; - IPv6 networking; - Bluetooth subsystem; - IP tunnels definitions; - IPv4 networking; - SCTP protocol; - XFRM subsystem; - io_uring subsystem; - IPC subsystem; - Audit subsystem; - BPF subsystem; - Control group (cgroup); - Kernel CPU control infrastructure; - Kernel exit() syscall; - Kernel futex primitives; - Locking primitives; - Scheduler infrastructure; - Signal handling mechanism; - Timer subsystem; - Tracing infrastructure; - Cryptographic library; - Debug objects infrastructure; - Resizable hashtable library; - Memory management; - 6LoWPAN network protocol; - IEEE 802 network protocols; - 9P file system network protocol; - Asynchronous Transfer Mode (ATM) subsystem; - B.A.T.M.A.N. meshing protocol; - Ethernet bridge; - CAN network layer; - Ceph Core library; - Ethtool driver; - HSR network protocol; - IEEE802154.4 network protocol; - IFE protocol; - IUCV driver; - KCM (Kernel Connection Multiplexor) sockets driver; - Logical Link layer; - MAC80211 subsystem; - IEEE 802.15.4 subsystem; - Management Component Transport Protocol (MCTP); - MultiProtocol Label Switching driver; - Multipath TCP; - NCSI (Network Controller Sideband Interface) driver; - NetLabel subsystem; - NFC subsystem; - Open vSwitch; - Packet sockets; - Phonet protocol; - Packet sampling (psample); - Qualcomm IPC Router (QRTR); - RDS protocol; - SMC sockets; - Sun RPC protocol; - TIPC protocol; - TLS protocol; - Unix domain sockets; - VMware vSockets driver; - Wireless networking; - X.25 network layer; - AppArmor security module; - Integrity Measurement Architecture(IMA) framework; - Apple Onboard Audio ALSA driver; - ALSA framework; - Generic PCM loopback sound driver; - FireWire sound drivers; - ESS Solo-1 ALSA driver; - HD-audio driver; - Simple audio multiplexer codec driver; - SoC Audio for Freescale CPUs drivers; - NVIDIA Tegra ASoC drivers; - USB sound devices; - Perf tools; (CVE-2023-54125, CVE-2023-54271, CVE-2025-22026, CVE-2025-23131, CVE-2025-39863, CVE-2025-39929, CVE-2025-39931, CVE-2026-23364, CVE-2026-31449, CVE-2026-31451, CVE-2026-31610, CVE-2026-31700, CVE-2026-31708, CVE-2026-31709, CVE-2026-31711, CVE-2026-31712, CVE-2026-31715, CVE-2026-43064, CVE-2026-43216, CVE-2026-43219, CVE-2026-43350, CVE-2026-43355, CVE-2026-43491, CVE-2026-43492, CVE-2026-45850, CVE-2026-45930, CVE-2026-45991, CVE-2026-45999, CVE-2026-46003, CVE-2026-46021, CVE-2026-46026, CVE-2026-46038, CVE-2026-46052, CVE-2026-46056, CVE-2026-46065, CVE-2026-46069, CVE-2026-46078, CVE-2026-46086, CVE-2026-46090, CVE-2026-46091, CVE-2026-46092, CVE-2026-46103, CVE-2026-46116, CVE-2026-46159, CVE-2026-46160, CVE-2026-46169, CVE-2026-46180, CVE-2026-46191, CVE-2026-46193, CVE-2026-46196, CVE-2026-46208, CVE-2026-46252, CVE-2026-46291, CVE-2026-46292, CVE-2026-46299, CVE-2026-46320, CVE-2026-46321, CVE-2026-46322, CVE-2026-52909, CVE-2026-52910, CVE-2026-52913, CVE-2026-52917, CVE-2026-52918, CVE-2026-52923, CVE-2026-52927, CVE-2026-52928, CVE-2026-52929, CVE-2026-52930, CVE-2026-52933, CVE-2026-52934, CVE-2026-52935, CVE-2026-52939, CVE-2026-52942, CVE-2026-52943, CVE-2026-52947, CVE-2026-52948, CVE-2026-52977, CVE-2026-53080, CVE-2026-53090, CVE-2026-53131, CVE-2026-53133, CVE-2026-53134, CVE-2026-53135, CVE-2026-53136, CVE-2026-53137, CVE-2026-53138, CVE-2026-53139, CVE-2026-53146, CVE-2026-53148, CVE-2026-53149, CVE-2026-53150, CVE-2026-53157, CVE-2026-53158, CVE-2026-53159, CVE-2026-53161, CVE-2026-53163, CVE-2026-53167, CVE-2026-53168, CVE-2026-53177, CVE-2026-53181, CVE-2026-53186, CVE-2026-53189, CVE-2026-53194, CVE-2026-53195, CVE-2026-53196, CVE-2026-53199, CVE-2026-53208, CVE-2026-53213, CVE-2026-53216, CVE-2026-53217, CVE-2026-53218, CVE-2026-53219, CVE-2026-53221, CVE-2026-53223, CVE-2026-53227, CVE-2026-53238, CVE-2026-53239, CVE-2026-53245, CVE-2026-53249, CVE-2026-53252, CVE-2026-53253, CVE-2026-53254, CVE-2026-53255, CVE-2026-53256, CVE-2026-53263, CVE-2026-53264, CVE-2026-53265, CVE-2026-53266, CVE-2026-53268, CVE-2026-53269, CVE-2026-53270, CVE-2026-53273, CVE-2026-53275, CVE-2026-53325, CVE-2026-53329, CVE-2026-53331, CVE-2026-53332, CVE-2026-53337, CVE-2026-53339, CVE-2026-53352, CVE-2026-53354, CVE-2026-53355, CVE-2026-53356, CVE-2026-53357, CVE-2026-53358, CVE-2026-53381, CVE-2026-53382, CVE-2026-53383, CVE-2026-53385, CVE-2026-53388, CVE-2026-53391, CVE-2026-53392, CVE-2026-53393, CVE-2026-53397, CVE-2026-53398, CVE-2026-53399, CVE-2026-53400, CVE-2026-53402, CVE-2026-53403, CVE-2026-63794, CVE-2026-63796, CVE-2026-63798, CVE-2026-63800, CVE-2026-63801, CVE-2026-63803, CVE-2026-63806, CVE-2026-63807, CVE-2026-63808, CVE-2026-63809, CVE-2026-63810, CVE-2026-63814, CVE-2026-63815, CVE-2026-63817, CVE-2026-63818, CVE-2026-63822, CVE-2026-63823, CVE-2026-63824, CVE-2026-63827, CVE-2026-63828, CVE-2026-63829, CVE-2026-63830, CVE-2026-63831, CVE-2026-63833, CVE-2026-63834, CVE-2026-63835, CVE-2026-63836, CVE-2026-63867, CVE-2026-63868, CVE-2026-63870, CVE-2026-63875, CVE-2026-63887, CVE-2026-63888, CVE-2026-63889, CVE-2026-63890, CVE-2026-63891, CVE-2026-63892, CVE-2026-63893, CVE-2026-63895, CVE-2026-63897, CVE-2026-63898, CVE-2026-63899, CVE-2026-63900, CVE-2026-63901, CVE-2026-63902, CVE-2026-63903, CVE-2026-63904, CVE-2026-63905, CVE-2026-63908, CVE-2026-63912, CVE-2026-63913, CVE-2026-63914, CVE-2026-63915, CVE-2026-63916, CVE-2026-63917, CVE-2026-63919, CVE-2026-63920, CVE-2026-63921, CVE-2026-63922, CVE-2026-63924, CVE-2026-63925, CVE-2026-63926, CVE-2026-63927, CVE-2026-63928, CVE-2026-63930, CVE-2026-63931, CVE-2026-63933, CVE-2026-63934, CVE-2026-63942, CVE-2026-63947, CVE-2026-63948, CVE-2026-63954, CVE-2026-63956, CVE-2026-63957, CVE-2026-63960, CVE-2026-63961, CVE-2026-63964, CVE-2026-63967, CVE-2026-63971, CVE-2026-63975, CVE-2026-63976, CVE-2026-63984, CVE-2026-63985, CVE-2026-63990, CVE-2026-63991, CVE-2026-63992, CVE-2026-63993, CVE-2026-63994, CVE-2026-64002, CVE-2026-64004, CVE-2026-64005, CVE-2026-64007, CVE-2026-64009, CVE-2026-64010, CVE-2026-64011, CVE-2026-64012, CVE-2026-64014, CVE-2026-64090, CVE-2026-64091, CVE-2026-64093, CVE-2026-64094, CVE-2026-64095, CVE-2026-64116, CVE-2026-64118, CVE-2026-64123, CVE-2026-64126, CVE-2026-64137, CVE-2026-64170, CVE-2026-64187, CVE-2026-64188, CVE-2026-64189, CVE-2026-64191, CVE-2026-64206, CVE-2026-64222, CVE-2026-64225, CVE-2026-64234, CVE-2026-64237, CVE-2026-64242, CVE-2026-64243, CVE-2026-64246, CVE-2026-64249, CVE-2026-64266, CVE-2026-64268, CVE-2026-64269, CVE-2026-64271, CVE-2026-64273, CVE-2026-64274, CVE-2026-64275, CVE-2026-64276, CVE-2026-64277, CVE-2026-64279, CVE-2026-64296, CVE-2026-64298, CVE-2026-64299, CVE-2026-64301, CVE-2026-64303, CVE-2026-64304, CVE-2026-64306, CVE-2026-64312, CVE-2026-64313, CVE-2026-64315, CVE-2026-64316, CVE-2026-64317, CVE-2026-64318, CVE-2026-64322, CVE-2026-64323, CVE-2026-64324, CVE-2026-64329, CVE-2026-64330, CVE-2026-64331, CVE-2026-64332, CVE-2026-64333, CVE-2026-64334, CVE-2026-64335, CVE-2026-64336, CVE-2026-64337, CVE-2026-64338, CVE-2026-64340, CVE-2026-64342, CVE-2026-64343, CVE-2026-64344, CVE-2026-64346, CVE-2026-64347, CVE-2026-64350, CVE-2026-64351, CVE-2026-64352, CVE-2026-64355, CVE-2026-64359, CVE-2026-64360, CVE-2026-64361, CVE-2026-64362, CVE-2026-64363, CVE-2026-64364, CVE-2026-64370, CVE-2026-64371, CVE-2026-64372, CVE-2026-64373, CVE-2026-64374, CVE-2026-64375, CVE-2026-64379, CVE-2026-64380, CVE-2026-64381, CVE-2026-64390, CVE-2026-64401, CVE-2026-64403, CVE-2026-64408, CVE-2026-64411, CVE-2026-64412, CVE-2026-64413, CVE-2026-64420, CVE-2026-64422, CVE-2026-64423, CVE-2026-64425, CVE-2026-64428, CVE-2026-64429, CVE-2026-64430, CVE-2026-64432, CVE-2026-64435, CVE-2026-64436, CVE-2026-64438, CVE-2026-64440, CVE-2026-64441, CVE-2026-64442, CVE-2026-64443, CVE-2026-64444, CVE-2026-64445, CVE-2026-64446, CVE-2026-64448, CVE-2026-64450, CVE-2026-64452, CVE-2026-64454, CVE-2026-64455, CVE-2026-64456, CVE-2026-64461, CVE-2026-64462, CVE-2026-64465, CVE-2026-64468, CVE-2026-64469, CVE-2026-64470, CVE-2026-64471, CVE-2026-64475, CVE-2026-64478, CVE-2026-64483, CVE-2026-64484, CVE-2026-64487, CVE-2026-64488, CVE-2026-64494, CVE-2026-64495, CVE-2026-64496, CVE-2026-64497, CVE-2026-64500, CVE-2026-64503, CVE-2026-64504, CVE-2026-64505, CVE-2026-64510, CVE-2026-64512, CVE-2026-64514, CVE-2026-64524, CVE-2026-64527, CVE-2026-64528, CVE-2026-64529, CVE-2026-64530, CVE-2026-64532, CVE-2026-64533, CVE-2026-64534, CVE-2026-64535, CVE-2026-64536, CVE-2026-64537, CVE-2026-64538, CVE-2026-64540, CVE-2026-64541, CVE-2026-64543, CVE-2026-64544, CVE-2026-64545, CVE-2026-64546, CVE-2026-64547, CVE-2026-64548, CVE-2026-64549, CVE-2026-64550, CVE-2026-64551, CVE-2026-64553, CVE-2026-64554, CVE-2026-64560, CVE-2026-64562, CVE-2026-64563, CVE-2026-64564, CVE-2026-64565, CVE-2026-64567, CVE-2026-64569, CVE-2026-64571, CVE-2026-64572, CVE-2026-64573, CVE-2026-64576, CVE-2026-64578, CVE-2026-64579, CVE-2026-64582, CVE-2026-64583, CVE-2026-64584, CVE-2026-64593, CVE-2026-64594, CVE-2026-64599, CVE-2026-64600, CVE-2026-64602, CVE-2026-64604, CVE-2026-68088, CVE-2026-68090, CVE-2026-68091, CVE-2026-68104, CVE-2026-68106, CVE-2026-68111, CVE-2026-68115, CVE-2026-68117, CVE-2026-68121, CVE-2026-68123, CVE-2026-68125, CVE-2026-68127, CVE-2026-68129, CVE-2026-68131, CVE-2026-68135, CVE-2026-68137, CVE-2026-68140, CVE-2026-68141, CVE-2026-68142, CVE-2026-68143, CVE-2026-68144, CVE-2026-68151, CVE-2026-68153, CVE-2026-68154, CVE-2026-68155, CVE-2026-68156, CVE-2026-68157, CVE-2026-68158, CVE-2026-68160, CVE-2026-68175, CVE-2026-68176, CVE-2026-68180, CVE-2026-68182, CVE-2026-68183, CVE-2026-68184, CVE-2026-68186, CVE-2026-68187, CVE-2026-68188, CVE-2026-68190, CVE-2026-68192, CVE-2026-68195, CVE-2026-68196, CVE-2026-68197, CVE-2026-68199, CVE-2026-68204, CVE-2026-68209, CVE-2026-68212, CVE-2026-68213, CVE-2026-68214, CVE-2026-68215, CVE-2026-68216, CVE-2026-68217, CVE-2026-68218, CVE-2026-68222, CVE-2026-68223, CVE-2026-68226, CVE-2026-68227, CVE-2026-68229, CVE-2026-68231, CVE-2026-68234, CVE-2026-68243, CVE-2026-68244, CVE-2026-68248, CVE-2026-68249, CVE-2026-68250, CVE-2026-68284, CVE-2026-68294, CVE-2026-68297, CVE-2026-68299, CVE-2026-68300, CVE-2026-68301, CVE-2026-68304, CVE-2026-68309, CVE-2026-68313, CVE-2026-68315, CVE-2026-68320, CVE-2026-68322, CVE-2026-68324, CVE-2026-68325, CVE-2026-68326, CVE-2026-68327, CVE-2026-68328, CVE-2026-68331, CVE-2026-68333, CVE-2026-68335, CVE-2026-68338, CVE-2026-68340, CVE-2026-68349, CVE-2026-68350, CVE-2026-68351, CVE-2026-68352, CVE-2026-68353, CVE-2026-68354, CVE-2026-68355, CVE-2026-68357, CVE-2026-68360, CVE-2026-68361, CVE-2026-68363, CVE-2026-68365, CVE-2026-68366, CVE-2026-68368, CVE-2026-68369, CVE-2026-68370, CVE-2026-68373, CVE-2026-68376, CVE-2026-68377, CVE-2026-68388, CVE-2026-68395, CVE-2026-68397, CVE-2026-68398, CVE-2026-68402, CVE-2026-68403, CVE-2026-68405, CVE-2026-68406, CVE-2026-68410, CVE-2026-68411, CVE-2026-68413, CVE-2026-68414, CVE-2026-68417, CVE-2026-68422, CVE-2026-68425, CVE-2026-68428, CVE-2026-68430, CVE-2026-68432, CVE-2026-68433, CVE-2026-68444, CVE-2026-68446, CVE-2026-68449, CVE-2026-68450, CVE-2026-68451, CVE-2026-68452, CVE-2026-68456, CVE-2026-68459, CVE-2026-68460, CVE-2026-68461, CVE-2026-68466, CVE-2026-68467, CVE-2026-68469, CVE-2026-68474, CVE-2026-68475, CVE-2026-68477, CVE-2026-68478, CVE-2026-68479, CVE-2026-68480, CVE-2026-72004, CVE-2026-72005, CVE-2026-72010, CVE-2026-72013, CVE-2026-72014, CVE-2026-72019, CVE-2026-72020, CVE-2026-72021, CVE-2026-72022, CVE-2026-72024, CVE-2026-72025, CVE-2026-72033, CVE-2026-72036, CVE-2026-72038, CVE-2026-72039, CVE-2026-72046, CVE-2026-72047, CVE-2026-72048, CVE-2026-72049, CVE-2026-72052, CVE-2026-72054, CVE-2026-72055, CVE-2026-72056, CVE-2026-72061, CVE-2026-72066, CVE-2026-72067, CVE-2026-72068, CVE-2026-72074, CVE-2026-72076, CVE-2026-72078, CVE-2026-72079, CVE-2026-72081, CVE-2026-72082, CVE-2026-72083, CVE-2026-72084, CVE-2026-72085, CVE-2026-72086, CVE-2026-72088, CVE-2026-72102, CVE-2026-72105, CVE-2026-72107, CVE-2026-72108, CVE-2026-72109, CVE-2026-72113, CVE-2026-72114, CVE-2026-72115, CVE-2026-72116, CVE-2026-72117, CVE-2026-72118, CVE-2026-72119, CVE-2026-72120, CVE-2026-72121, CVE-2026-72122, CVE-2026-72123, CVE-2026-72124, CVE-2026-72125, CVE-2026-72126, CVE-2026-72129, CVE-2026-72133, CVE-2026-72135, CVE-2026-72136, CVE-2026-72138, CVE-2026-72140, CVE-2026-72146, CVE-2026-72153, CVE-2026-72159, CVE-2026-72160, CVE-2026-72163, CVE-2026-72164, CVE-2026-72165, CVE-2026-72166, CVE-2026-72167, CVE-2026-72171, CVE-2026-72181, CVE-2026-72182, CVE-2026-72192, CVE-2026-72193, CVE-2026-72194, CVE-2026-72195, CVE-2026-72197, CVE-2026-72215, CVE-2026-72218, CVE-2026-72219, CVE-2026-72223, CVE-2026-72224, CVE-2026-72225, CVE-2026-72226, CVE-2026-72228, CVE-2026-72229, CVE-2026-72230, CVE-2026-72231, CVE-2026-72232, CVE-2026-72233, CVE-2026-72234, CVE-2026-72235, CVE-2026-72238, CVE-2026-72240, CVE-2026-72241, CVE-2026-72245, CVE-2026-72247, CVE-2026-72250, CVE-2026-72251, CVE-2026-72256, CVE-2026-72264, CVE-2026-72265, CVE-2026-72267, CVE-2026-72268, CVE-2026-72269, CVE-2026-72270, CVE-2026-72271, CVE-2026-72272, CVE-2026-72274, CVE-2026-72275, CVE-2026-72276, CVE-2026-72282, CVE-2026-72289, CVE-2026-72296, CVE-2026-72297, CVE-2026-72298, CVE-2026-72306, CVE-2026-72307, CVE-2026-72310, CVE-2026-72314, CVE-2026-72316, CVE-2026-72319, CVE-2026-72322, CVE-2026-72326, CVE-2026-72339, CVE-2026-72347, CVE-2026-72348, CVE-2026-72349, CVE-2026-72350, CVE-2026-72351, CVE-2026-72371, CVE-2026-72374, CVE-2026-72378, CVE-2026-72389, CVE-2026-72392, CVE-2026-72396, CVE-2026-72400, CVE-2026-72406, CVE-2026-72409, CVE-2026-72414, CVE-2026-72418, CVE-2026-72421, CVE-2026-72422, CVE-2026-72428, CVE-2026-72433, CVE-2026-72435, CVE-2026-72441, CVE-2026-72447, CVE-2026-72448, CVE-2026-72450, CVE-2026-72459, CVE-2026-72460, CVE-2026-72466, CVE-2026-72476, CVE-2026-72479, CVE-2026-72481, CVE-2026-72483, CVE-2026-72484, CVE-2026-72489, CVE-2026-72491, CVE-2026-72492, CVE-2026-72502, CVE-2026-74255, CVE-2026-74256, CVE-2026-74262, CVE-2026-74265, CVE-2026-74267, CVE-2026-74276, CVE-2026-74279, CVE-2026-74280, CVE-2026-74281, CVE-2026-74282, CVE-2026-74283, CVE-2026-74284, CVE-2026-74287, CVE-2026-74288, CVE-2026-74292, CVE-2026-74293, CVE-2026-74295, CVE-2026-74297, CVE-2026-74305, CVE-2026-74312, CVE-2026-74313, CVE-2026-74320, CVE-2026-74321, CVE-2026-74327, CVE-2026-74329, CVE-2026-74330, CVE-2026-74331, CVE-2026-74339, CVE-2026-74340, CVE-2026-74346, CVE-2026-74348, CVE-2026-74349, CVE-2026-74351, CVE-2026-74359, CVE-2026-74363, CVE-2026-74376, CVE-2026-74379, CVE-2026-74382, CVE-2026-74384, CVE-2026-74390, CVE-2026-74394, CVE-2026-74395, CVE-2026-74398, CVE-2026-74399, CVE-2026-74402, CVE-2026-74408, CVE-2026-74410, CVE-2026-74416, CVE-2026-74424, CVE-2026-74426, CVE-2026-74427, CVE-2026-74438, CVE-2026-74443, CVE-2026-74444, CVE-2026-74453, CVE-2026-74455, CVE-2026-74456, CVE-2026-74457, CVE-2026-74458, CVE-2026-74459, CVE-2026-74460, CVE-2026-74461, CVE-2026-74463, CVE-2026-74464, CVE-2026-74465, CVE-2026-74467, CVE-2026-74468, CVE-2026-74469, CVE-2026-74471, CVE-2026-74473, CVE-2026-74475, CVE-2026-74478, CVE-2026-74480, CVE-2026-74481, CVE-2026-74482, CVE-2026-74485, CVE-2026-74488, CVE-2026-74490, CVE-2026-74492, CVE-2026-74493, CVE-2026-74495, CVE-2026-74497, CVE-2026-74498, CVE-2026-74499, CVE-2026-74505, CVE-2026-74507, CVE-2026-74508, CVE-2026-74512, CVE-2026-74518, CVE-2026-74519, CVE-2026-74523, CVE-2026-74525, CVE-2026-74540, CVE-2026-74546, CVE-2026-74547, CVE-2026-74548, CVE-2026-74549, CVE-2026-74556, CVE-2026-74557, CVE-2026-74563, CVE-2026-74564, CVE-2026-74566, CVE-2026-74567, CVE-2026-74569, CVE-2026-74577, CVE-2026-74578, CVE-2026-74579, CVE-2026-74580, CVE-2026-74581, CVE-2026-74583, CVE-2026-74584, CVE-2026-74585, CVE-2026-74586, CVE-2026-74587, CVE-2026-74588, CVE-2026-74589, CVE-2026-74597, CVE-2026-74598, CVE-2026-74604, CVE-2026-74609, CVE-2026-74613, CVE-2026-74614, CVE-2026-74615, CVE-2026-74616, CVE-2026-74620, CVE-2026-74622, CVE-2026-74625, CVE-2026-74630, CVE-2026-74635, CVE-2026-74636, CVE-2026-74641, CVE-2026-74648, CVE-2026-74649, CVE-2026-74650, CVE-2026-74651, CVE-2026-74654, CVE-2026-74656, CVE-2026-74657, CVE-2026-74658, CVE-2026-74659, CVE-2026-74660, CVE-2026-74664, CVE-2026-74667, CVE-2026-74669, CVE-2026-74671, CVE-2026-74673, CVE-2026-74675, CVE-2026-74676, CVE-2026-74679, CVE-2026-74680, CVE-2026-74682, CVE-2026-74683, CVE-2026-74688, CVE-2026-74691, CVE-2026-74692, CVE-2026-74693, CVE-2026-74694, CVE-2026-74696, CVE-2026-74697, CVE-2026-74701, CVE-2026-74704, CVE-2026-74705, CVE-2026-74717, CVE-2026-74719, CVE-2026-74720, CVE-2026-74726, CVE-2026-74730, CVE-2026-80591, CVE-2026-80593, CVE-2026-80594, CVE-2026-80595, CVE-2026-80597, CVE-2026-80598, CVE-2026-80599, CVE-2026-80600, CVE-2026-80601, CVE-2026-80603, CVE-2026-80605, CVE-2026-80609, CVE-2026-80613, CVE-2026-80619, CVE-2026-80622, CVE-2026-80626, CVE-2026-80627, CVE-2026-80630, CVE-2026-80644, CVE-2026-80645, CVE-2026-80646, CVE-2026-80647, CVE-2026-80649, CVE-2026-80652, CVE-2026-80659, CVE-2026-80664, CVE-2026-80677, CVE-2026-80679, CVE-2026-80680, CVE-2026-80681, CVE-2026-80706, CVE-2026-80707, CVE-2026-80708, CVE-2026-80714, CVE-2026-80716, CVE-2026-80717, CVE-2026-80718, CVE-2026-80722, CVE-2026-80731, CVE-2026-80732, CVE-2026-80733, CVE-2026-80867, CVE-2026-80875, CVE-2026-80876, CVE-2026-80877, CVE-2026-80879, CVE-2026-80880, CVE-2026-80881, CVE-2026-80886, CVE-2026-80890, CVE-2026-80902, CVE-2026-89774)

Ontinue has announced the launch of ION for Dark Web Monitoring (DWM), a new managed add-on service that extends ION MXDR to continuously identify exposed credentials, detect brand impersonation attempts, and uncover emerging external threats before attackers can exploit them. Compromised credentials are traded across criminal forums, lookalike domains are created to impersonate trusted brands, and sensitive information can surface across deep and dark web sources long before security teams become aware of the exposure. … More → The post Ontinue extends ION MXDR with managed dark web monitoring appeared first on Help Net Security .

Analysis of Blinder Tunnel, an Iran-nexus campaign using fake Dubai Airports recruitment lures and GitHub C2 malware to target critical infrastructure. The post Blinder Tunnel Campaign Targets Iraqi Infrastructure appeared first on Unit 42 .

UK education software provider Bromcom has notified customers of a personal data breach affecting its single sign-on (SSO) technology. In a September 24 EduGeek post, an account named Bromcom_Alastair said an unauthorized third party had accessed and retrieved email addresses and limited information associated with affected SSO registrations. The incident involved legacy SSO registration functionality in Bromcom's Communication Server environment. The company confirmed in an FAQ it found no evidence that its school Management Information System (MIS), used to manage student data, attendance, behaviour, and administration, was compromised. Bromcom said it was working with external forensic specialists to determine the nature and scope of the data involved. The company identified the incident on September 6 after reports of SSO access problems and has since withdrawn the legacy functionality from production. The service held email addresses associated with SSO registrations, the provider used, such as Microsoft or Google, registration and last sign-in dates where recorded, and internal user and registration reference numbers. Bromcom said the affected component did not hold account passwords or authentication tokens. The legacy SSO registration functionality had remained in production after being superseded because "it was still being called by an internal system," the supplier said. The incident did not enable access to Microsoft or Google accounts, whose authentication services are separate from the affected component said Bromcom. The Register has asked Bromcom to comment further. Bromcom provides information management software used in schools and the wider education sector in the UK. It offers tools for budgeting, timetabling, HR, and benchmarking. Bromcom's software is used by more than 5,000 schools and 390 multi-academy trusts (organizations that run multiple schools). Recent customer wins include Newport City Council, the Ministry of Defence, Warwickshire County Council, and the Northern Ireland Education Authority. ® Updated to add at 0834 UTC, October 6 A spokesperson for Bromcom said: "We recently identified, contained and began investigating an IT incident. Our investigation is ongoing to determine the nature and scope of any data involved, and we have already taken steps to resolve any disruption. We are liaising with the relevant schools and trusts, as well as the appropriate authorities."

The age of LLM-assisted security vulnerability discovery is really starting to bite. Debian's latest Linux kernel security update comes with a formidable reading list of 1,313 CVE identifiers. The DSA-6528-1 Linux security advisory, published on September 29, covers kernel package version 6.12.111-1 for Debian 13, codenamed Trixie. Debian 13.7 was released on September 12, before upstream kernel 6.12.111 arrived nine days later. The Debian security tracker links to descriptions of the individual issues. We have not examined every entry. If we had, this article would not appear until after Debian 13.8 (which is likely to appear later in October), or possibly at some point in 2027. Several checked at random also affect older kernel versions, so the list should not be read as a tally of bugs introduced in 6.12.111. The Linux kernel project became a CVE Numbering Authority (CNA) in February 2024. Back in February this year, kernel maintainer Greg Kroah-Hartman described the Linux CVE assignment process in some detail. He said kernel development averages around nine changes an hour, with a feed of known bug fixes averaging about 30 changes a day providing the basis for the CNA team's review. The kernel team's policy is to assign CVEs automatically after fixes have reached a stable kernel tree. It takes a deliberately cautious approach because the security implications of a bug may not be apparent when it is fixed. A CVE identifier alone therefore says little about severity or exploitability. We strongly suspect that this number of CVEs is due to LLM bots doing the bug hunting, and quite possibly doing the bug fixing as well. Linux is not an anti-AI project, and neither is Debian. AI-assisted bug hunting is already swamping the Linux security mailing list, as The Register reported in May. Kroah-Hartman released kernel 6.12.112 on October 3. Its detailed changelog runs to more than 27,000 lines. With both the rates of change and the sizes of the changes getting so large, it is hard to deny that LLM bot assistance must be very useful to the hard-pressed maintainers. Whether coding bots constitute a net benefit to the projects, to software, or to humanity as a whole remains at best an open question. ®

Microsoft confirmed over the weekend that some games and applications using AC-3 (Dolby Digital) audio decoding will crash after installing the September 2026 KB5124010 Windows 11 preview update. [...]

UK education software provider Bromcom has notified customers of a personal data breach affecting its single sign-on (SSO) technology. In a September 24 EduGeek post, an account named Bromcom_Alastair said an unauthorized third party had accessed and retrieved email addresses and limited information associated with affected SSO registrations. The incident involved legacy SSO registration functionality in Bromcom's Communication Server environment. The company confirmed in an FAQ it found no evidence that its school Management Information System (MIS), used to manage student data, attendance, behaviour, and administration, was compromised. Bromcom said it was working with external forensic specialists to determine the nature and scope of the data involved. The company identified the incident on September 6 after reports of SSO access problems and has since withdrawn the legacy functionality from production. The service held email addresses associated with SSO registrations, the provider used, such as Microsoft or Google, registration and last sign-in dates where recorded, and internal user and registration reference numbers. Bromcom said the affected component did not hold account passwords or authentication tokens. The legacy SSO registration functionality had remained in production after being superseded because "it was still being called by an internal system," the supplier said. The incident did not enable access to Microsoft or Google accounts, whose authentication services are separate from the affected component said Bromcom. The Register has asked Bromcom to comment further. Bromcom provides information management software used in schools and the wider education sector in the UK. It offers tools for budgeting, timetabling, HR, and benchmarking. Bromcom's software is used by more than 5,000 schools and 390 multi-academy trusts (organizations that run multiple schools). Recent customer wins include Newport City Council, the Ministry of Defence, Warwickshire County Council, and the Northern Ireland Education Authority. ®

Dell has released security updates to address multiple critical security flaws in Dell Container Storage Modules (CSM) that could be exploited by bad actors to take over susceptible systems. The vulnerabilities are listed below - CVE-2026-63688 (CVSS score: 10.0) - A missing authentication for critical function vulnerability in the csm-authorization-storage gRPC server that an

California's attorney general has subpoenaed OpenAI as the state investigates what happens when the AI lab's models escape their testing environments and start meddling with systems on the open internet. Attorney General Rob Bonta said his office served OpenAI with an investigative subpoena this week as part of a broader California Department of Justice probe into cybersecurity incidents and risks involving the company and its models. The move follows an investigation launched last month into an incident involving Hugging Face, after OpenAI's agents managed to break out of their test environments and onto the public internet. They then went poking around Hugging Face's systems, with one agent even creating an account on the platform without being told to. California's DoJ isn't saying exactly what it has demanded from OpenAI under the subpoena, but Bonta said the state wants more information about cybersecurity incidents involving the company. "My office is asking OpenAI additional questions regarding cybersecurity incidents and risks involving the company and its AI models," Bonta said. He also made clear that the investigation is looking at where responsibility lies when an AI model ends up doing something its developer didn't intend. "Frontier models can be legitimate tools for cyber defense — at the same time, companies that develop these models and offer them for use have a moral and legal responsibility to ensure that they do not perpetrate or enable cyberattacks, either during model testing and development or once models are placed into service," Bonta said. "Developers that fail to do so can and should be held legally accountable, and my office is committed to determining if that is the case here." The subpoena doesn't mean California has concluded OpenAI broke the law, and the attorney general's office hasn't identified any specific violation. For now, the state is still gathering information. But the investigation has been building for several weeks. In September, Bonta joined a bipartisan group of 25 attorneys general calling on Congress to regulate large-scale AI models following reports of cybersecurity incidents at frontier AI labs. That letter specifically pointed to reports that OpenAI models undergoing evaluations had escaped their testing environments, reached the public internet, and accessed outside computer systems. The attorneys general called for a government-led incident response regime that would give investigators direct access to AI companies' records when things go awry. Bonta's office now appears to be putting some of that thinking into practice at the state level. As The Reg previously pointed out, the sandboxes intended to contain these agents need to be more secure, which is the most logical reasons why the Hugging Face and other incidents happened in the first place. OpenAI didn’t respond to our questions. ®

On September 15 this year, Google published details of patches for 110 vulnerabilities in its own Google Pixel smartphones. Among all the disclosed flaws, CVE-2026-58704 stands out the most, for it appears that this zero-day is being exploited in targeted attacks. In today’s post, we talk about what’s so special about the Google Pixel, and why these devices get security updates all of their own – separate from regular Android updates. We also cover the vulnerabilities addressed in this latest update, with a special focus on the mentioned, most dangerous one – CVE-2026-58704 – and wrap up with tips on how to both protect your device and avoid becoming a victim of cyberattack on it. Why do Google Pixel phones get security updates separate from Android? The reader might reasonably wonder: I’ve already installed this month’s Android security updates on my Google Pixel. Isn’t that the same thing? Google Pixel does run on Android and receives those security updates, which are detailed in the monthly Android Security Bulletin . However, manufacturers of Android-based devices use different sets of hardware and software components. That’s why, alongside vulnerabilities common to all Android devices, there are security issues specific to individual manufacturers’ devices. For its own smartphones, Google publishes separate security updates, covered by a dedicated Pixel Update Bulletin . Rather than replacing the Android Security Bulletin, this document complements it by detailing vulnerabilities specific to devices manufactured by Google. Other Android smartphones also receive similar updates from their manufacturers. The Pixel Update Bulletin for September 2026 clearly shows why Google needs separate updates for its smartphones in the first place. Many of the vulnerabilities it fixes affect specific Pixel hardware (or hardware-related) components: the modem, bootloader, GPU, fingerprint scanner components, and other parts of the device. On smartphones from other manufacturers, these features might rely on entirely different hardware and software components, so the fixes listed in the Pixel Update Bulletin don’t apply to those phones. That said, these vulnerabilities could still be relevant for Pixel owners who’ve flashed their devices with custom ROMs. Switching to a different OS doesn’t alter the device’s hardware components, and may not replace the firmware. Therefore, the vulnerabilities themselves may persist, but whether patches are available, and how they’re installed, depends on the specific OS. CVE-2026-58704: a zero-day vulnerability being actively exploited in the wild Now let’s look closer at the specific vulnerabilities Google fixed in September. The most significant one is the above-mentioned CVE-2026-58704 . This vulnerability affects the Cellular Modem component, which handles the smartphone’s communication with cellular networks. It stems from a logic error in the code, which, under certain conditions, allows bypassing the intended permission check. Successful exploitation of CVE-2026-58704 lets attackers escalate privileges on the smartphone to gain broader access to its functions and data. Note that the attack takes place over a cellular network and the threat actors need low-level privileges on the targeted device to start with. In practice, this means attackers can’t exploit CVE-2026-58704 to attack a Pixel from just anywhere over the internet, as they’d apparently need to either compromise the cellular network the target smartphone is already connected to or, more likely, force it to connect to a malicious base station under their control. Google hasn’t disclosed all the details of this vulnerability yet, and the related report is not publicly accessible. As a result, the technical details that would show how easy it is for attackers to exploit CVE-2026-58704 remain unknown pending installation of the patches on all devices. Nevertheless, Google claims that there are signs of limited exploitation of CVE-2026-58704. What we know about the other 109 vulnerabilities Of the remaining 109 vulnerabilities found in Google Pixel devices, only one is rated moderate; the others are either high (62) or outright critical (46). Nine of these flaws fall into the RCE (remote code execution) category. This means that if an attacker successfully exploits one of these vulnerabilities, they can remotely force the device to run malicious code. The exact conditions for the attack depend on the specific vulnerability. Another 88 vulnerabilities fall into the elevation of privilege (EoP) category. These let an attacker who’s already gained a certain level of access to the device expand their privileges. The CVE-2026-58704 vulnerability discussed above falls into this same category, which is why the September bulletin lists 89 EoP vulnerabilities in total. Finally, 10 vulnerabilities can lead to information disclosure (ID), and two more to denial of service (DoS). In short, that’s a hefty list of flaws, so Google Pixel owners shouldn’t wait around to install the patches. How to avoid becoming a victim Google Pixel owners can install the update that fixes the vulnerabilities covered in this post by following this path: Settings → Security &amp; privacy → System &amp; updates → Security update → Install . Keep in mind that the phone will automatically restart to finish installing the update. To keep your phone secure we recommend the following general measures: Install security updates on your phone regularly and promptly – whether it’s a Google Pixel, an Android smartphone from a different manufacturer, or even an iPhone. Avoid installing apps from questionable sources. Read reviews before installing apps from official stores, since malware isn’t uncommon there too . Users who have already been burned will often sound the alarm in the reviews long before store moderators get around to removing the dangerous app. Install&nbsp; a reliable security solution &nbsp;to keep you from downloading malware, and warn you about suspicious activity on your device.

Fortinet is warning customers to lock down FortiMail after attackers started exploiting a critical bug that lets them write files to vulnerable systems without logging in. The flaw, tracked as CVE-2026-104286, carries a CVSS score of 9.8 and affects multiple versions of Fortinet's email security platform. Fortinet describes the vulnerability as a combination of path traversal and improper handling of null characters in FortiMail's web interface. An unauthenticated attacker can exploit it using specially crafted HTTP or HTTPS requests to write arbitrary files to the underlying system. Writing files to certain locations could allow an attacker to execute code or commands on the appliance. Fortinet says the flaw affects FortiMail versions 8.0.0 through 8.0.1, 7.6.0 through 7.6.6, 7.4.0 through 7.4.8, and 7.2.0 through 7.2.9. The vendor's advisory says CVE-2026-104286 "is being exploited in the wild," although it doesn't say when the attacks began, who is behind them, or how many customers may have been compromised. It has, however, published indicators administrators can hunt for on their systems. These include suspicious files and configuration changes, along with IP addresses associated with the attacks. CISA has added CVE-2026-104286 to its Known Exploited Vulnerabilities catalog, directing US federal civilian agencies to carry out forensic triage and apply mitigations by October 4. Fortinet lists fixes for several affected branches as "upcoming," leaving customers on those versions reliant on workarounds until updates arrive. In the meantime, Fortinet recommends disabling Identity Based Encryption if it isn't required. Where that's not possible, customers should prevent the FortiMail management interface from being reachable from the internet and restrict access to trusted private networks. Administrators should also check for signs of compromise: applying a workaround will not remove any files or persistence mechanisms attackers may already have planted. It's not Fortinet's first encounter with attackers making themselves at home on its network appliances this year. In June, credentials linked to around 75,000 FortiGate firewalls turned up in criminal hands, though Fortinet said the data came from previous incidents and brute-force attacks rather than a fresh breach. ®

This week, the useful words are boring ones: inspect, cache, compile, store, trust. Each sounds harmless. Each can become an attack path when a system does a little more than people expect. A model check can run code. A cache can mix up requests. A public secret can stay useful for years. That is the lesson running through the list. Attackers do not always need a brilliant new trick. They can

Secure file-sharing software company Kiteworks has released security updates to address 126 vulnerabilities, including a max-severity flaw affecting its Email Protection Gateway (EPG) security solution. [...]