Search: t**n*e**l s.a. c***t**c***a

Microsoft has fixed a known issue causing the June 2026 security updates to fail on Windows Server 2016 systems that weren't up to date. [...]

8cc is vulnerable to an Out‑of‑Bounds Read due to improper handling of #line directives and GNU linemarkers. The compiler accepts attacker-controlled filename and line number metadata and later uses it without validation when accessing source line arrays. By supplying invalid or oversized line numbers, an attacker can trigger out-of-bounds memory access and a crash. Maintainer of this project was notified early about this vulnerability, but didn't respond with the details of vulnerability or vulnerable version range. Version corresponding to the commit b480958 was tested and confirmed as vulnerable, other versions were not tested but might also be vulnerable.

Backpropagate is a Python library for fine-tuning large language models on a single GPU. In versions 1.1.0 and 1.1.1, the optional Reflex web UI exposes a training control plane without authentication: dataset upload, model load, training start/stop, multi-run orchestration, GGUF export, and HuggingFace Hub push. The CLI accepts two operator-facing flags intended as security controls: --auth user:pass — documented as "require HTTP Basic authentication on every request to the UI." and--share — documented as "expose the UI on a public address; requires --auth." When --auth user:pass is passed, the CLI prints Auth: enabled (user: <username>) to confirm to the operator that authentication is active, then exports BACKPROPAGATE_UI_AUTH=user:pass to the subprocess that launches the Reflex backend. The Reflex backend (backpropagate/ui_app/**) never reads BACKPROPAGATE_UI_AUTH. No authentication middleware is registered. No request-level guard runs. No WebSocket upgrade guard runs. Any client that reaches the bound port — local or remote, depending on whether --share is used — has full UI access. An inline comment at backpropagate/cli.py:1217-1218 in the v1.1.0 source documents the gap: "For Phase 1 the variable is exported but Reflex doesn't read it yet." This comment was internal-facing; the user-facing documentation (README, CHANGELOG, SHIP_GATE) advertised the contract as enforced. An attacker who reaches the bound port can read uploaded datasets, trigger arbitrary training runs against any local base models as well as read their paths, trigger HuggingFace Hub pushes and cause disk-fill DoS. This issue has been fixed in version 1.2.0. If developers cannot immediately upgrade to 1.2.0 run backprop ui with no flags so it binds to localhost, use SSH port-forwarding (ssh -L 7860:localhost:7860 <training-host>) instead of --share for remote access, and audit any host previously launched with --share, re-issuing any HF tokens used during those sessions.

To allow builds of Python to be run from an in-tree layout (rather than an installed file layout), the VPATH variable is defined at build time and used to locate certain landmarks - specifically, Modules/setup.local. When this landmark is found relative to VPATH relative to the executable, Python assumes it is running in a source tree and generates a different default sys.path. This code remains in release builds, so that release-ready builds can be built in-tree. On Windows, since builds are written to 'PCbuild/', the value of VPATH is set to '..\..', which results in a landmark of '..\..\Modules\setup.local'. This path is outside the install directory of Python, and may have different permissions, potentially allowing a low-privilege user to create the landmark and an alternative `Lib` folder that will be discovered by an otherwise restricted install. Such a setup occurs with the legacy default install location for all users (in the now superseded EXE installer), due to how Windows allows all users to create folders in the root directory of their OS drive. Our recommended mitigation on Windows is to migrate away from the legacy installer and use the new [Python install manager](https://www.python.org/downloads/latest/pymanager/) to install for the current user. Installs where the directory two levels above the Python installation directory have equivalent permissions are unaffected (in general, a per-user install cannot be modified at all by other users, removing any escalation of privilege risk, and could be directly modified by a privileged user, making the potential tampering irrelevant). Alternative mitigations might include preemptively creating and restricting access to a `Modules` directory. Be aware that only 3.13 and 3.14 will receive updated legacy installers - earlier fixes are only provided as sources. Platforms other than Windows allow VPATH to be overridden, but as they don't usually use a separated directory in the build for binaries, are unlikely to have a landmark reference outside of the install directory. The landmark detection involving VPATH is a fallback for when a more specific landmark - .\pybuilddir.txt - is absent, and was included for compatibility. Future releases of Python will no longer include the fallback, and so builds will need to generate or preserve the pybuilddir.txt file in order to work in-tree. This landmark file has been generated on Windows since 3.11, and on other platforms for longer.

Discover how continuous control validation in Tenable One can improve your CTEM program by filtering out alert noise and factoring in your active cyber defenses. Focus your team on accessible and exploitable attack paths. Key takeaways: With vulnerability exploitation ranking as the top initial access vector and frontier AI accelerating vulnerability discovery, organizations must shift from managing theoretical cyber risks to validating actual, accessible exposure. Tenable One maps active security controls including EDR, MFA, and firewalls directly onto potential attack paths, allowing teams to automatically deprioritize weaknesses that existing defenses already neutralize. Ingesting penetration testing results via the Tenable One Open Connector allows organizations to layer real-world attack simulations over real-time exposure insights to identify toxic risk combinations that threaten critical assets. Your security tools probably indicate you have thousands, perhaps tens or hundreds of thousands, of vulnerabilities across your environment. Maybe your tools prioritize these vulnerabilities based on CVSS scores or other criteria, but how do you know which vulnerabilities combine with other preventable security risks, like misconfigured cloud buckets and identity weaknesses, to create attack paths threat actors could realistically traverse? How do you validate which vulnerabilities an existing security control mitigates? You need this context to distinguish the real risks from the theoretical ones to ensure your team focuses on remediating what matters most. The work of validating, prioritizing, and remediating vulnerabilities alongside other security weaknesses to understand the true exposure they create has become much more urgent, as frontier AI models accelerate vulnerability discovery. In this environment, the traditional patch-based defense model will get crushed. Moreover, defenders cannot afford inaccurate decision-making and wasted remediation work that addresses low-priority vulnerabilities. They desperately need the context and validation that a continuous threat exposure management (CTEM) program provides. This is why security leaders are evolving their vulnerability management programs to exposure management programs. Exposure management allows you to continually assess your attack surface, prioritize risks , and orchestrate automated remediation of security weaknesses at machine speed. Exposure management also helps validate which exposures attackers can actually reach by understanding the accessibility and exploitability of an attack path. It uses validation to shift your organization from managing theoretical risks to executing on actual exposure. What is exposure validation in CTEM? Validation is one of the five steps in the CTEM lifecycle. It is the process of providing consistent, continuous, and automated evidence of an attack’s feasibility. It stress-tests your defenses against real-world attack conditions, using your own environment’s controls and configurations to confirm whether an exposure is genuinely reachable and exploitable. Validation moves security from a reactive “patch everything” mindset to a preemptive, evidence-based exposure strategy . It continuously confirms which weaknesses your existing defenses have already blocked and surfaces the ones that demand immediate attention. Expanded CTEM validation capabilities in Tenable One Validation isn’t new to Tenable: we’ve been using validation techniques in Tenable solutions for more than 25 years. Tenable developed nearly 3,000 direct check plugins to actively probe a vulnerability and prove its exploitability in situations where software version detection isn’t sufficient for our high-accuracy standards. These plugins actually mimic attack techniques and monitor the target’s response to confirm the presence of the vulnerability. What is new in Tenable One is the addition of continuous control validation in the platform. By factoring in your active security controls, Tenable One helps eliminate the noise of theoretically exposed assets that are functionally blocked from exploitation. Security teams can visually map their active prevention and detection controls directly onto potential attack paths, automatically prioritizing weaknesses that existing controls already neutralize. Analysts can also filter top attack paths based on the presence of security controls and whether you can prevent attack chains for faster triage and investigation. Common control validation examples include: Endpoint detection and response (EDR) tools that block Local Security Authority Subsystem Service (LSASS) memory dump tools used to harvest credentials. Multi-factor authentication (MFA) methods that prevent unauthorized access via password guessing , password spraying , or credential stuffing . Firewall and data loss prevention (DLP) tools that prevent data exfiltration by detecting data staging and enforcing egress rules. See how continuous control validation works in Tenable One. Proactively manage risk prioritization with continuous security control validation. Eliminate noise from theoretical risks that are functionally blocked by existing defenses by integrating compensating security controls into the exposure prioritization process. Access a unified dashboard where assets, vulnerabilities, and exposure risks are consolidated. Filter attack paths to identify which are protected by compensating controls. View types of compensating controls deployed in the environment. Examine attack paths that could be protected with endpoint protection tools. Review security controls associated with specific attack paths, including SIEM and EDR controls. Inspect individual nodes within attack paths to determine which security controls are protecting them. Identify assets monitored by SIEM tools such as Splunk. Verify endpoint protection coverage on assets, including Microsoft Defender installations. Filter attack techniques to focus on specific threats like LSASS Memory techniques, which extract credentials from compromised systems and can be mitigated by endpoint protection tools. Identify attack paths and assets lacking appropriate EDR coverage. Prioritize remediation by examining high-priority attack paths where compensating controls are absent. Collaborate with security control owners to confirm coverage and address gaps in protection for critical assets. Integrate penetration testing data into Tenable One Beyond direct check plugins and continuous control validation, security teams can also integrate penetration testing results into Tenable One that simulate real-world attacks against your cyber defenses. This is another way to validate which exposures are truly exploitable and contextualizes them against your broader attack surface. The Tenable One Open Connector makes it easy to ingest the latest pentest results and layer them with real-time exposure insights to turn your findings into active, continuous defenses. Integrating pentest data into an exposure management program adds critical context to help you understand toxic risk combinations and enrich your understanding of high-severity weaknesses that threaten your most critical business assets. Context is essential in exposure management In the AI era, your security team can’t waste precious time on the wrong issues. With exposure management, context is essential to pinpoint the most critical risks to your organization. Security control validation, coupled with asset criticality, threat activity, entitlement privileges, and attack pathways, give your security team the advantage it needs to stay ahead of threat actors. Learn more about Tenable One , the exposure management platform for the modern attack surface.

Versions prior to 2.6.6 are vulnerable to prototype pollution via crafted missing-key strings when used to persist missing translation keys (e.g. via i18next-http-middleware's missingKeyHandler exposed to untrusted input). Backend.writeFile() splits each queued missing-key string on the configured keySeparator (default .) before calling the internal setPath() walker. The walker (getLastOfPath in lib/utils.js) did not guard against unsafe segments, so a key like "__proto__.polluted" was split into ["__proto__", "polluted"] and walked straight into Object.prototype, allowing an attacker to write arbitrary properties onto the global object prototype. Depending on the host application, polluted prototype properties may cause crashes, corrupted translation behaviour, configuration poisoning, or bypasses of property-based security checks. Applications are affected only if the missingKeyHandler (or another route that forwards untrusted request bodies to i18next.t(..., { ... }) with saveMissing: true) is reachable by untrusted users and the default behaviour of splitting missing-key strings on keySeparator is in use (i.e. keySeparator is not false). Apps that do not expose missing-key persistence to untrusted input are not directly affected through this attack path. This issue has been fixed in version 2.6.6. If developers using the library are unable to upgrade immediately, they should take the following precautions: do not expose i18next-http-middleware's missingKeyHandler to untrusted users (mount it behind authentication, or remove the route), disable missing-key persistence (saveMissing: false, or no backend.create implementation) when accepting writes from untrusted input, and set keySeparator: false in their i18next options to disable backend key splitting (note: this also disables nested translation keys).

A flaw has been found in Intelbras iNVU 7016 FT 3.004.00IB000.0.T Build 2025-09-26. This impacts an unknown function of the file /RPC2_Loadfile/syslog/ of the component Web Interface. Executing a manipulation can lead to path traversal. The attack can be launched remotely. The exploit has been published and may be used. It is recommended to upgrade the affected component. The vendor was contacted early, responded in a very professional manner and quickly released a fixed version of the affected product.

### Summary A vulnerability in Fleet's labels host-listing endpoint allowed authenticated users with the lowest-privilege Observer role to extract host enrollment secrets (`node_key`, `orbit_node_key`) through a cursor-based binary search oracle. The endpoint accepted a user-supplied `order_key` parameter that was not validated against a column allowlist, permitting sort order to be driven by sensitive columns in a joined table. ### Impact The `GET /api/v1/fleet/labels/{id}/hosts` endpoint constructs its query using a deprecated helper that did not restrict which columns could appear in the `ORDER BY` clause. An attacker with Global Observer or Team Observer credentials could supply a sensitive column name (for example, `h.node_key`) as `order_key` and combine it with the cursor-based `after` parameter to binary-search the values of those columns one character at a time. The targeted values never appeared in the response body, but the presence or absence of results revealed each character. The `node_key` and `orbit_node_key` values are the long-lived shared secrets used by osquery and Orbit agents to authenticate to the Fleet server. An attacker who extracted these keys could: - Impersonate enrolled hosts to Fleet's osquery and Orbit endpoints - Submit fabricated query results and host inventory data - Retrieve pending scripts and MDM commands queued for the host - Poison compliance and policy results across the Fleet deployment Exploitation required authenticated Observer access. Fleet deployments that restrict Observer roles to fully trusted users were at lower practical risk, but the secrets exposed are high-value and long-lived. ### Patches - v4.85.0 ### Workarounds If an immediate upgrade is not possible, administrators should: - Restrict the Observer role to fully trusted users until the patch is applied - Rotate `node_key` and `orbit_node_key` for any host suspected of exposure by re-enrolling the affected hosts ### For more information If there are any questions or comments about this advisory: Email Fleet at [security@fleetdm.com](mailto:security@fleetdm.com) Join #fleet in [osquery Slack](https://join.slack.com/t/osquery/shared_invite/zt-h29zm0gk-s2DBtGUTW4CFel0f0IjTEw) ### Credits Fleet thanks the Security Team at Palantir Technologies for responsibly reporting this issue.

Other noteworthy stories that might have slipped under the radar: ICS device exposure remains flat as attack surface widens, Microsoft issues incident response playbook for AI, IBM and AT&#038;T accused of hack cover-ups. The post In Other News: Google Security Layoffs, AudiA6 Takedown, $400 Million Coupang Fine appeared first on SecurityWeek .

This update for python fixes the following issues - CVE-2026-1703: files may be extracted outside the installation directory when installing and extracting maliciously crafted wheel archives (bsc#1257599). - CVE-2026-3219: pip doesn't reject concatenated ZIP (bsc#1262429). - CVE-2026-4786: Incomplete mitigation of %action expansion for command injection to webbrowser.open() (bsc#1262319). - CVE-2026-6019: BaseCookie.js_output() does not neutralize embedded characters (bsc#1262654). - CVE-2026-6100: arbitrary code execution or information disclosure via use-after-free in decompression modules (bsc#1262098). - CVE-2026-6357: pip self-update functionality can import newly installed modules after wheel installation (bsc#1263442). Changes for python: - For SLE-12-SP1 use vendored libffi (bsc#1261652). We have libffi4.so from SP3 only.

CISA issued BOD 26-04, which replaces BOD 22-01 with a four-variable vulnerability prioritization model requiring federal agencies to patch the most dangerous vulnerabilities in as few as three days. Key takeaways BOD 26-04 replaces BOD 22-01 with a four-variable risk model that assigns graduated remediation timelines, from as few as three days with mandatory forensic triage for the most dangerous vulnerabilities to full deferral for the lowest-risk ones, ending the era of flat, one-size-fits-all patching deadlines for federal agencies. The transition represents a significant operational lift at a time when AI is compressing the window between vulnerability disclosure and weaponization, and industry remediation rates are declining: only 26% of KEV vulnerabilities were fully remediated in 2025 according to the 2026 Verizon DBIR, down from 38% the prior year. Organizations that have invested in continuous asset discovery, risk-based prioritization, and exposure management are well positioned to operationalize the directive’s four-variable model. Those still relying on periodic scanning and CVSS-based prioritization face a significant gap between current capability and compliance requirements. Background on CISA BOD 26-04 On June 10, 2026, the Cybersecurity and Infrastructure Security Agency (CISA) issued Binding Operational Directive (BOD) 26-04, “Prioritizing Security Updates Based on Risk.” BOD 26-04 represents a fundamental shift in how federal agencies are expected to manage vulnerabilities. Rather than treating every known exploited vulnerability (KEV) with the same remediation deadline, the new directive introduces a graduated model that accounts for asset exposure, exploitation evidence, adversary automation capability, and technical impact severity. The result is a 16-tier remediation matrix where the most dangerous vulnerabilities must be patched within three days (with mandatory forensic triage), while lower-risk vulnerabilities can be deferred to the next system upgrade cycle. Tenable applauds this directive, which replaces both BOD 22-01 (Reducing the Significant Risk of Known Exploited Vulnerabilities, November 2021) and BOD 19-02 (Vulnerability Remediation Requirements for Internet-Accessible Systems, April 2019). It is directionally correct in Tenable’s view, and it represents a significant improvement upon its predecessors, as it consolidates seven years of federal vulnerability remediation policy into a single, risk-weighted framework. More importantly, it aligns with the risk-based, exposure-driven approach to vulnerability management that Tenable has championed as the originator of the exposure management paradigm. For years, Tenable has maintained the position that defenders must move beyond volume-based patching toward intelligent prioritization grounded in real-world exploitation evidence, asset context, and threat actor intelligence. BOD 26-04 codifies that position as federal policy. Frequently asked questions about BOD 26-04 What is BOD 26-04? BOD 26-04 is a binding operational directive from CISA that requires all Federal Civilian Executive Branch (FCEB) agencies to prioritize vulnerability remediation based on a four-variable risk model. Unlike its predecessor BOD 22-01, which assigned flat remediation timelines to all vulnerabilities in the KEV catalog, BOD 26-04 evaluates each vulnerability against four criteria and assigns a remediation deadline based on the specific combination of risk factors present. The directive is mandatory for federal agencies but not for the private sector. However, CISA explicitly encourages private sector adoption, and the track record of BOD 22-01 suggests the framework will become a de facto standard across industries. BOD 22-01’s KEV catalog is already used by organizations worldwide as a prioritization signal, and BOD 26-04’s more sophisticated model will likely follow the same adoption curve. What are the four variables? BOD 26-04 determines remediation urgency using four binary variables: Publicly exposed - Is the vulnerable asset reachable from outside the agency network via a routable IP address? This is the only variable agencies must determine themselves. In the KEV - Is the CVE listed in CISA’s Known Exploited Vulnerabilities catalog? This confirms real-world exploitation. Automatable by adversary - Can an attacker automate all the steps necessary to exploit the vulnerability? This assesses weaponization maturity. Technical impact - Does exploitation give attackers total control of the affected system or only partial control? CISA publishes the answers to variables two, three, and four for every CVE through its Vulnrichment Program. Agencies must determine variable one (public exposure) using their own asset inventory and CISA’s Internet Exposure Reduction Guidance. What are the remediation timelines? Table 1 in Appendix A of the directive maps all 16 possible combinations of the four binary variables to specific remediation deadlines across five tiers: Three days with forensic triage - Required when a vulnerability is in the KEV and yields total system control (regardless of whether the asset is publicly exposed or the exploit is automatable). This is the most aggressive vulnerability management timeline in federal directive history. The forensic triage component requires agencies to assess whether their systems have already been compromised. Three days (without forensic triage) - Required for certain high-risk combinations, such as a publicly exposed asset with an automatable vulnerability yielding total control, even if the CVE is not yet in the KEV. 14 days - The standard accelerated timeline for most KEV-listed vulnerabilities and several high-risk non-KEV combinations. 60 days - Applied to lower-risk combinations, such as non-exposed assets with automatable but partial-control vulnerabilities. Fix on system upgrade - Applied when no risk criteria are met. This is the deferral tier, and it represents a significant operational relief for agencies: vulnerabilities that meet none of the four criteria can wait for the next scheduled upgrade cycle. Timelines are dynamic. If an agency removes a system from public internet exposure, the applicable timeline shifts to a longer window. Conversely, if CISA adds a vulnerability to the KEV catalog, the remediation timeline accelerates immediately. In an initial analysis at one large civilian agency, CISA found that only 1% of vulnerability instances fell into the three-day category, while over 60% qualified for deferral to the next system upgrade. The model is designed to focus resources, not overwhelm them. What changed from BOD 22-01? BOD 26-04 revokes and replaces BOD 22-01 entirely. The key differences are substantial: BOD 22-01 applied a flat remediation timeline to every vulnerability in the KEV catalog (14 days for CVEs assigned after 2021, six months for older CVEs). BOD 26-04 replaces this with a graduated model where KEV status is one of four variables, not the sole determinant of urgency. A KEV vulnerability on an internal system with partial control and no automation capability now receives 14 days, while the same KEV on a publicly exposed system with full automation and total control receives just three days with mandatory forensic triage. BOD 22-01 had no deferral mechanism. Every KEV required action. BOD 26-04 introduces the “fix on system upgrade” tier for vulnerabilities that meet none of the four risk criteria, allowing agencies to focus on the ones that matter most rather than chasing every vulnerability with equal urgency. BOD 22-01 had no forensic triage requirement. BOD 26-04 introduces mandatory forensic analysis for the highest-risk tier, recognizing that when a vulnerability is actively exploited and yields total system control, patching alone is insufficient: organizations need to determine whether they’ve been compromised. The underlying methodology also shifts. BOD 22-01 relied primarily on the KEV catalog and CVSS scoring. BOD 26-04 is informed by CISA’s Stakeholder-Specific Vulnerability Categorization (SSVC) system, which provides a more nuanced, risk-informed vulnerability analysis methodology. Why did CISA issue BOD 26-04 now? Two converging factors drove the directive. The first is the deteriorating effectiveness of traditional vulnerability management. Citing the 2026 Verizon Data Breach Investigations Report, CISA’s blog post accompanying the directive notes that only 26% of KEV-listed vulnerabilities were fully remediated by organizations in 2025, a decline from 38% the previous year. Meanwhile, the median time to fully resolve vulnerabilities rose to 43 days. In an environment where exploitation can occur within hours of disclosure, the remediation gap is widening. The second factor is artificial intelligence. CISA explicitly states that AI is accelerating both vulnerability discovery and weaponization, narrowing the window of time that exists between vulnerability disclosure and exploitation. The directive aligns with priorities in the recent AI Executive Order , Promoting Advanced Artificial Intelligence Innovation and Security . As AI-enabled tools make it easier for adversaries to identify, weaponize, and deploy exploits at scale, the traditional “patch everything eventually” approach becomes untenable. Defenders need a framework that tells them what to patch first, and BOD 26-04 provides the framework enabling them to prioritize on an accelerated timeframe. This is a challenge Tenable has been tracking closely. The intersection of an AI-enabled threat landscape with already-declining remediation effectiveness creates a compounding problem: adversaries are getting faster while defenders fall farther behind. BOD 26-04 is a necessary policy response to this environment. I don’t work for a federal agency. How does BOD 26-04 affect my organization? While BOD 26-04 is mandatory only for FCEB agencies, its influence extends well beyond the federal government. BOD 22-

In this week’s newsletter, Amy reminisces on the tech toys of their childhood, inspired by a hilarious lesson about why your digital privacy shouldn't be left on an open channel.

Svelte devalue is a JavaScript library that serializes values into strings when JSON.stringify isn't sufficient for the job. From version 5.6.3 to before version 5.8.1, devalue.parse could, due to quirks in some JavaScript engines, be convinced to allocate much more memory than was needed when deserializing sparse arrays, leading to excessive memory consumption. This issue has been patched in version 5.8.1.

CVE-2026-46323 is a high-severity vulnerability in the Linux kernel's Generic Receive Offload (GRO) networking subsystem. It arises from improper handling of zerocopy socket buffers (skbs) in the skb_gro_receive() function, specifically when the SKBFL_MANAGED_FRAG_REFS flag is set. This flaw can lead to a Use-After-Free (UAF) condition by incorrectly merging skbs without adjusting page reference counts. Exploitation could cause system instability or potentially allow arbitrary code execution. The issue affects Linux kernel version 6.0. Fixes have been committed to the kernel source. No effective mitigation other than applying the fix is currently available according to Red Hat advisories.

When ALLOW_INSECURE_RAW_TEXT is enabled, whitespace-variant closing tags (e.g., </style\t>) are not recognized by the sanitizer but accepted by browsers as valid end tags, allowing subsequent content to escape sanitization. This allows bypassing the cross-site scripting prevention mechanism of typo3/html-sanitizer before version 2.3.2.

In the Linux kernel, the following vulnerability has been resolved: dm: fix a buffer overflow in ioctl processing Tony Asleson (using Claude) found a buffer overflow in dm-ioctl in the function retrieve_status: 1. The code in retrieve_status checks that the output string fits into the output buffer and writes the output string there 2. Then, the code aligns the "outptr" variable to the next 8-byte boundary: outptr = align_ptr(outptr); 3. The alignment doesn't check overflow, so outptr could point past the buffer end 4. The "for" loop is iterated again, it executes: remaining = len - (outptr - outbuf); 5. If "outptr" points past "outbuf + len", the arithmetics wraps around and the variable "remaining" contains unusually high number 6. With "remaining" being high, the code writes more data past the end of the buffer Luckily, this bug has no security implications because: 1. Only root can issue device mapper ioctls 2. The commonly used libraries that communicate with device mapper (libdevmapper and devicemapper-rs) use buffer size that is aligned to 8 bytes - thus, "outptr = align_ptr(outptr)" can't overshoot the input buffer and the bug can't happen accidentally

Between April and May 2026, a likely North Korean threat actor conducted phishing campaigns targeting developers across nearly 100 organizations in finance, cryptocurrency, education, and technology sectors. The attacks used recruitment and code review themes, delivering emails with links to actor-controlled GitHub repositories hosting malicious scripts. The infection chain exploited Visual Studio Code workflows and deployed malicious Visual Studio Extensions (VSIX) requiring minimal user interaction. Cross-platform malware was executed on macOS, Linux, and Windows systems, including the open-source Overlord framework. The campaigns specifically targeted developer assets including API tokens, cryptocurrency wallets, and credentials. Attackers employed fake company personas and professional-looking repositories masquerading as legitimate cryptocurrency and blockchain projects to establish credibility and lure victims.

Malware#wallet exfiltration#ottercookieUnited States

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (e2041887c315474d0722cbf717e189ec1260e209c5f00da5ca3a52a60c6aebb2) The package name `rsquests` is a single-character insertion typo of the top-100 PyPI package `requests`. Package metadata and source are a verbatim copy of upstream `requests`: `rsquests/__version__.py` sets `__title__ = "requests"`, METADATA lists `Author-email: Kenneth Reitz <me@kennethreitz.org>`, and `top_level.txt` declares the top-level package as `requests` (so `import requests` after installing `rsquests` resolves to this package's bundled copy, shadowing the real upstream if it isn't installed). The full public API (get/post/put/delete/Session/...) is replicated, so a developer who mistypes `pip install requests` as `pip install rsquests` gets working behavior and may not notice the substitution. No exfiltration, RCE, dropper, credential harvest, or silent-relay payload is present in this version — the install-time and import-time code paths match the upstream library. The risk is name-confusion plus future-version risk: the squatted name normalizes the typo and provides a vector if a later release introduces a malicious payload. Routing to human review per typosquat-without-payload policy — name-similarity is a subjective signal and the absence of a current payload means this does not meet the bar for an automated block. ## Source: kam193 (b32959e10bc6b1df57d105a5e5d74cbe7b69660cb7a1e78185d3f5e0e0f07e10) Typosquatting package published from a compromised account with an obfuscated infostealer. The infostealer is a heavily obfuscated JavaScript code executed using Bun runtime on Python startup. It collectes all kinds of sensitive data, including API keys, credentials to package repositories, cryptocurrency assets, password manager data. Infostealer actively queries online services to collect additional secrets as well as attempts to gain persistence and spread further by publishing infected packages using collected credentials. Data are exfiltrated likely using Github. The code seems to threaten to wipe the user's data if it detects invalid GitHub tokens. Cleanup should be done with caution. It seems to be related to the recent Mini Shai Hulud campaign. --- Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers. Campaign: 2026-06-compr-woodpecker Reasons (based on the campaign): - compromised-package - exfiltration-env-variables - exfiltration-cloud-tokens - exfiltration-credentials - abuses-pth - obfuscation - infostealer - The package contains code to detect if it is running in a sandbox environment. - exfiltration-crypto - files-exfiltration - destructive-actions

On June 2, 2026, the White House signed an Executive Order directing federal agencies to harden their systems with AI-enabled cyber defenses and to stand up a new AI cybersecurity clearinghouse — most of it on a 30-day clock. Here’s what the EO requires and how Tenable can help. Key takeaways: The new AI Security Executive Order will require national security and civilian federal agencies to prioritize cyber defenses to account for new frontier AI model capabilities. Tenable is well positioned to help federal agencies gain visibility across their environments, including AI assets, and to prioritize the vulnerabilities and other exposures that pose the highest risk; Tenable AI-enabled exposure management capabilities can help support vulnerability remediation and automate multi-step remediation workflows. The vulnerability and patching clearinghouse which will be developed under the Executive Order will require strong engagement from private sector partners, including Tenable, to drive actionable insights on AI-associated vulnerabilities and mitigation prioritization. On June 2, 2026, the President signed an Executive Order (EO) titled “ Promoting Advanced Artificial Intelligence Innovation and Security .” The direction is clear and the calls to action are fast-moving. Within 30 days: Federal agencies must begin hardening their information systems with AI-enabled cyber defenses. CISA must issue new directives or guidance for civilian agencies. The Department of the Treasury (Treasury), with the National Security Agency (NSA) and the Cybersecurity and Infrastructure Security Agency (CISA), must stand up a new AI cybersecurity clearinghouse focused on finding and fixing software vulnerabilities. Within 60 days, Treasury, with the Department of War (DoW), NSA and CISA, in consultation with the White House and other agencies, must establish a classified benchmarking process to assess the capabilities of frontier AI models through voluntary collaboration with AI developers. While the Executive Order applies to U.S. federal agencies, the need to prepare for changes in the threat landscape brought about by the advanced cyber capabilities of frontier AI models applies to any organization that needs to manage cyber risk. Here’s a breakdown of what the AI EO requires, the deadlines that matter, and where Tenable fits. What the AI Executive Order requires The EO’s operative provisions sit in Section 2 (“Upgrading American systems for advanced AI”) and Section 3 (“Secure frontier model deployment”). The cybersecurity core is in Section 2. Within 30 days: National security and defense systems. The Committee on National Security Systems must prioritize the cyber defense of National Security Systems (NSS) and the Secretary of War must do the same for DoW information systems (Section 2(a) and 2(b)). Civilian federal systems and critical infrastructure. CISA, in consultation with the Office of Management and Budget (OMB), the Assistant to the President for National Security Affairs, and the National Cyber Director, must release Binding Operational Directives (BODs) “and other guidance as appropriate” to: Expedite and prioritize the cyber defense of civilian federal information systems. Establish or expand federal programs and services that enhance AI-enabled defensive tools. Facilitate access to cybersecurity tools and services, including where appropriate, covered frontier models, for agencies, state and local authorities, and critical infrastructure operators such as rural hospitals, community banks, and local utilities. Worth noting, while the EO directs CISA to release BODs or other guidance for federal civilian agencies, the specific implementation directives are not yet known (Section 2(c)). The AI cybersecurity clearinghouse. The Secretary of the Treasury, with the National Cyber Director, NSA, and CISA, must form an AI cybersecurity clearinghouse, in voluntary collaboration with the AI industry and critical infrastructure operators. The EO tasks the clearinghouse with three concrete functions, per Section 2(d): Coordinate and deconflict scanning for software vulnerabilities Discover and validate those vulnerabilities Coordinate and prioritize the remediation and distribution of vulnerability patches. Grant funding for AI vulnerability detection. OMB, with the National Cyber Director and CISA, must determine whether existing federal grant programs have funding that can be directed toward applicants developing advanced AI vulnerability detection (Section 2(e)). Within 60 days: Cybersecurity workforce. The Office of Personnel Management must expand hiring and placement pathways for cybersecurity specialists through the United States Tech Force (Section 2(f)). Secure frontier model deployment. Treasury, NSA, and CISA, in consultation with NIST and others, must develop a classified benchmarking process to assess the advanced cyber capabilities of AI models. They must also set the threshold for designating a “covered frontier model,” and design a voluntary framework through which developers can give the government up to 30 days of pre-release access to those models. The Executive Order is explicit that it does not create any mandatory licensing, preclearance, or permitting requirement for AI models (Section 3). No fixed deadline: Criminal enforcement. The EO directs the Attorney General to prioritize enforcement against those who use AI to illegally access or damage computer systems (Section 4). For federal cybersecurity leaders, this is less a future-state policy document than a near-term planning trigger. Watch for CISA’s issuance of BODs and other guidance, and for readouts on the clearinghouse, during June and July. How Tenable can help The EO’s center of gravity — finding software vulnerabilities, validating them, prioritizing them, and driving remediation — is the work Tenable's platform is built to do. While the AI Executive Order focuses on vulnerability discovery, validation, prioritization, and remediation, the benefit of the Tenable One Exposure Management Platform is that it addresses vulnerabilities alongside other security weaknesses, including misconfigurations of AI systems and overpermissioned AI agents, to serve as the system of action for mitigating cyber exposure and reducing cyber risk across organizations’ expanding attack surfaces. Below, learn how specific Tenable capabilities map to the EO’s requirements. Continuous vulnerability detection across the attack surface Sections 2(a) through 2(d) turn on the ability to find vulnerabilities across a wide range of systems continuously. Tenable One Vulnerability Management and Tenable Security Center provide network-based and agent-based assessment across IT assets, with credentialed scanning for greater depth. Tenable One Cloud Exposure extends that visibility to cloud workloads and configurations, and Tenable One Attack Surface Management maps internet-facing assets that agencies may not know they have. For agencies operating classified or air-gapped environments — relevant to the National Security Systems named in Section 2(a) — Tenable Enclave Security is built to run vulnerability and configuration assessment inside those boundaries. Risk-based prioritization, not “patch everything” Section 2(d) doesn’t only call for discovering vulnerabilities — it calls for prioritizing them for remediation. That distinction matters because no agency can patch everything at once. Tenable’s Vulnerability Priority Rating (VPR) uses machine learning, trained on the company’s corpus of more than 1.7 trillion security findings accumulated over more than 25 years of continuous scanning, to forecast which vulnerabilities are most likely to be exploited, so defenders can focus on the smaller set that represents real, immediate risk. By leveraging AI-generated features and expert intelligence from Tenable's Research Special Operations team, VPR helps organizations pinpoint the critical 1.6% of vulnerabilities that represent actual business risk . Tenable also ingests CISA’s Known Exploited Vulnerabilities (KEV) catalog — the continuously updated, authoritative list of Common Vulnerabilities and Exposures (CVEs) under active exploitation — directly into prioritization, aligning remediation guidance to the same source CISA uses to track risk across the federal enterprise. AI-enabled defensive tooling Section 2(c) directs CISA to establish or expand programs that enhance AI-enabled defensive tools. As frontier AI models accelerate the rate at which vulnerabilities can be discovered and exploited , the traditional window for manual remediation is rapidly closing. The June 2026 AI Executive Order recognizes this shift, directing federal agencies to counter machine-speed threats with AI-enabled cyber defenses within 30 days. Tenable Hexa AI , the agentic engine of the Tenable One Exposure Management Platform , is designed to help counter machine-speed threats, supercharge productivity, and accelerate risk reduction by automating multi-step remediation workflows. Security teams can leverage pre-built agents directly in the user interface or build custom agents via the Model Context Protocol (MCP), turning exposure intelligence into decisive action at machine speed. At the same time, as agencies build custom models or adopt third-party tools like ChatGPT and Copilot, they fundamentally expand their attack surface. It is now critical to protect enterprise AI, shadow AI, training data, and underlying infrastructure from emerging threats like adversarial attacks, data poisoning, and model theft. Tenable secures this expanding attack surface with Tenable One AI Exposure , which is designed to help agencies see, manage, and control the risks introduced by generative AI. Tenable One AI Exposure allows agencies to discover and inventory AI tools and libraries, and apply AI usage policies across the environment — a growing requirement as agencies adopt AI and need to account for it as part of