Search: discovery.com

A DPRK-aligned threat group is targeting developers through fake job postings and coding challenges in a campaign tracked as REF9403. Attackers post fake job offers in developer forums, then send trojanized repositories containing fully functional e-commerce projects with malicious code hidden using steganography inside SVG flag images. When developers run these projects, the malware deploys four-stage payloads aligned with OTTERCOOKIE: a browser credential and cryptocurrency wallet stealer, a file exfiltration module, a Socket.IO-based remote access trojan, and a clipboard stealer. The campaign was discovered after targeting Elastic's community Slack workspace. Multiple trojanized repositories were found with zero antivirus detections at the time of discovery, demonstrating the sophistication of this supply chain attack vector against software developers.

Microsoft released an unprecedented 622 vulnerability patches in July's Patch Tuesday, with 62 critical severity issues and three zero-days, two actively exploited. This represents more vulnerabilities than all of 2018 combined and marks a dramatic shift from the typical five patches issued in July two years prior. Microsoft attributes this surge to AI frontier model-accelerated vulnerability research. While major vendors like Microsoft possess resources to handle this volume, smaller companies face significant challenges. The concern extends beyond discovery to deployment, as traditional IT patch testing and stability review processes struggle under this unprecedented load. Organizations must differentiate between temporary surges and the new normal operational tempo, as continuous high-volume patching may become standard. This situation places extraordinary pressure on IT administrators and change management teams who must adapt to a sustained flood of KEV and EPSS notifications while maintaining infrast...

Malware#castlestealer#starland ratUnited States

ToolHive is a utility designed to simplify the deployment and management of Model Context Protocol (MCP) servers. Prior to 0.31.0, remote.Handler.Authenticate in pkg/auth/remote/handler.go invokes discovery.DetectAuthenticationFromServer in pkg/auth/discovery/discovery.go, whose host-side HTTP clients trust remote-server-controlled authentication discovery destinations, follow redirects without host or scheme restrictions, and do not consistently block private addresses. A malicious or compromised remote MCP server can place a resource_metadata URL in WWW-Authenticate for ParseWWWAuthenticate to extract, after which FetchResourceMetadata, OIDC issuer discovery, and well-known discovery can issue GET requests to link-local, RFC1918, or other internal services outside the server's container. The user connects to a server that the user intends to use, but the server controls the internal destination; this path does not depend on the separate NAT64 guard omission because the affected clients did not invoke IsPrivateIP, and it differs from the DCR resolver path that already refused redirects. The demonstrated primitive reaches internal-only HTTP services and reachability or error oracles, and can retrieve AWS metadata credentials where IMDSv1 accepts an unauthenticated GET, while IMDSv2 and GCP metadata prerequisites are not satisfied by the demonstrated request. This vulnerability is fixed in 0.31.0.

Vaultwarden is a Bitwarden-compatible server written in Rust. Prior to 1.36.0, Vaultwarden's /icons/{domain}/icon.png endpoint used src/http_client.rs checks including should_block_address() and post_resolve() that missed decimal, hexadecimal, and octal IP representations, allowing SSRF through the icon-fetching HTTP client for blind internal network or port discovery. This issue is fixed in version 1.36.0.

Vaultwarden is a Bitwarden-compatible server written in Rust. Prior to 1.36.0, Vaultwarden's SSO discovery and pre-validation flow returned organization-related SSO metadata including organizationIdentifier values for arbitrary email addresses and allowed a valid pre-validation JWT to be obtained with only the discovered identifier, enabling SSO-enabled organization enumeration and authentication workflow abuse. This issue is fixed in version 1.36.0.

Microsoft Corp. today released software updates to plug at least 570 security holes in its Windows operating systems and other software, almost triple the number of vulnerabilities the software giant fixed in its record-smashing Patch Tuesday release last month. Microsoft attributed the burgeoning patch counts to vulnerability discoveries aided by artificial intelligence. Nearly 60 of the bugs quashed in July’s Patch Tuesday earned a “critical” severity rating, meaning miscreants or malware could use them to seize remote control over a Windows device with little or no help from the user. Microsoft also addressed three zero-day flaws, including two that are already being exploited in the wild. Two of the zero-day weaknesses allow an attacker to elevate their user rights on a Windows system, as do approximately 250 other elevation of privilege flaws fixed this month; they include CVE-2026-56155 — an Active Directory Federation Services bug — and CVE-2026-56164 , a Microsoft Sharepoint vulnerability. CVE-2026-50661 is a security feature bypass in Windows BitLocker that could allow attackers to gain access to encrypted data if they have physical access to the device. Microsoft said this bug has been detailed publicly, but that it is not aware of any active exploitation. In a blog post on July 9, Microsoft Executive Vice President Pavan Davuluri wrote that Windows users will notice “a higher volume of security updates included in each security release” as a result of AI aiding in the discovery of vulnerabilities. “The pace of vulnerability discovery is changing with advances in AI making it possible to find more issues, faster, across more code, with new mechanisms that can accelerate both discovery and analysis,” Davuluri wrote . Jack Bicer , director of vulnerability research at Action1 , called attention to CVE-2026-48561 , a remote code execution flaw in Microsoft Copilot (with a 9.6 CVSS threat score) that allows an unauthorized attacker to execute code over the network. Microsoft says an attacker could exploit this bug by hosting a malicious website that causes Microsoft Edge for Android to automatically send crafted prompts to Copilot when a user visits the site. As AI advances the state of vulnerability discovery and remediation, it is also making it easier for attackers to quickly devise working exploits for known software flaws. Microsoft has long labeled security bugs using its “exploitability index,” which is Redmond’s best guess as to how likely it is that attackers will be able to figure out a reliable way to exploit a given vulnerability. But Satnam Narang , senior staff research engineer at Tenable , argues that Microsoft’s exploitability index needs to do a better job of shifting with the machine speed of discovery. For example, Microsoft originally gave this month’s SharePoint zero-day an exploitability rating of “less likely,” although the flaw was added to CISA’s Known Exploited Vulnerabilities list on July 1. “Anthropic’s Red Team’s own findings for known vulnerabilities (n-days) revealed how fragile this system has become, with its Mythos Preview model being able to produce proof-of-concept exploits for 13 of 14 vulnerabilities that were rated ‘Exploitation Less Likely’ or ‘Exploitation Unlikely,'” Narang said. “What this means is that our way of looking at Patch Tuesday has changed, because the exploitability index is centered around humans, not AI tools, and as these tools continue to improve, defense needs to improve alongside it.” Chris Goettl at Ivanti observed that the record patch numbers from Microsoft come as a number of other major software makers are increasing their patch cadence, including Adobe which announced today it is moving to twice-monthly security bulletins published on the 2nd and 4th Tuesday of each month (Adobe also cited AI for accelerating their patch cycles). Cisco , Mozilla and Oracle also are shipping updates more frequently, while Google’s patch batches in June 2026 totaled more t…

# Project custom command templates can read outside-workspace files into model prompts ## Summary PraisonAI's new file-based custom command feature auto-discovers project commands from `.praisonai/commands/*.md`. When a user runs `praisonai run --command <name>` inside a repository, the command body is interpolated before it is sent as the model prompt. The interpolation code expands `@path` references by reading files relative to the current working directory, but it does not canonicalize the target or require it to stay inside the project. A repository-controlled command can therefore include `@../outside_secret.txt` or an absolute path and cause PraisonAI to copy process-readable files outside the workspace into the prompt. This is a confidentiality issue in the untrusted-repository workflow: a project can make a normal-looking custom command exfiltrate local files to whichever model/provider receives the generated prompt. ## Technical Details The feature was introduced by commit `88cf0c29` (`feat: file-based custom agents and reusable commands with auto-discovery (#2035)`) and is present on current main: ```text current commit: 3aa9cbc2bd49c23a32be0a89a5e620d13d843eab current describe: v4.6.64-8-g3aa9cbc2 ``` `src/praisonai/praisonai/cli/features/custom_definitions.py` discovers project-level definitions by walking upward from `Path.cwd()` to the git root and loading `.praisonai/commands/*.md`. Project commands override user-global commands. `interpolate_command_template()` loads the selected command and passes the command body to the interpolator with `Path.cwd()` as the working directory: ```python return interpolator.interpolate(command.template, arguments, Path.cwd()) ``` `TemplateInterpolator._interpolate_files()` then matches every `@([^\s]+)` token and reads the referenced file: ```python if working_dir: file_path = working_dir / file_path_str else: file_path = Path(file_path_str) if file_path.exists() and file_path.is_file(): with open(file_path, 'r') as f: return f.read() ``` There is no `resolve()` call and no containment check against the project root. In Python, `Path.cwd() / "/absolute/path"` returns the absolute path, and parent traversal such as `../outside_secret.txt` resolves outside the workspace when opened. The sink is in `src/praisonai/praisonai/cli/commands/run.py`: the `--command` path calls `interpolate_command_template()`, then passes the fully interpolated prompt to `_run_prompt()`. ## PoV A minimal vulnerable repository only needs a project command template and an outside file: ```text workspace/ .git/ .praisonai/ commands/ relative_escape.md # contains @../outside_secret.txt absolute_escape.md # contains an absolute path outside workspace inside.txt outside_secret.txt ``` When the operator runs the project command, PraisonAI discovers `.praisonai/commands/*.md`, interpolates the template with `Path.cwd()` as the working directory, reads the outside file, and passes the resulting prompt to `_run_prompt()`. The controls in the PoC below show the expected asymmetry: an in-workspace file expands, a missing file remains literal, shell substitution is escaped, and both parent traversal and absolute outside-file references disclose the outside canary. ## PoC From a fresh PraisonAI checkout, run the following command. The checkout path is passed as the first Python argument, and the script sets up the source import path itself; no hidden `PYTHONPATH` setup is required. ```bash git clone https://github.com/MervinPraison/PraisonAI.git cd PraisonAI git checkout 3aa9cbc2bd49c23a32be0a89a5e620d13d843eab python3 - "$PWD" <<'PY' from __future__ import annotations import importlib.util import json import os import subprocess import sys import tempfile import types from pathlib import Path CANARY = "PRAISONAI_CUSTOM_COMMAND_CANARY=outside-workspace" def install_yaml_fallback_if_needed() -> str: if importlib.util.find_spec("yaml") is not None: return "installed" yaml_stub = types.ModuleType("yaml") class YAMLError(Exception): pass def safe_load(text: str): data = {} for raw_line in text.splitlines(): line = raw_line.strip() if not line or line.startswith("#") or ":" not in line: continue key, value = line.split(":", 1) data[key.strip()] = value.strip().strip("'\"") return data yaml_stub.safe_load = safe_load yaml_stub.YAMLError = YAMLError sys.modules["yaml"] = yaml_stub return "stubbed" def add_source_to_path(source_root: Path) -> None: candidate = source_root / "src" / "praisonai" if (candidate / "praisonai").exists(): sys.path.insert(0, str(candidate)) return raise SystemExit(f"Could not find PraisonAI sources below {source_root}") class pushd: def __init__(self, path: Path): self.path = path self.old = Path.cwd() def __ent

Cisco Talos&#x2019; Vulnerability Discovery & Research team recently disclosed three vulnerabilities in WolfSSF, fourteen in GeoVision, and one vulnerability in VTK-DICOM. The vulnerabilities mentioned in this blog post have been patched by their respective vendors, in adherence to Cisco&#x2019;s third-party vulnerability disclosure policy .&#xA0; For

This content is a news roundup highlighting 20 new open-source cybersecurity tools, many focused on AI security. The tools cover areas such as AI endpoint discovery, AI agent telemetry, static analysis, container security, autonomous penetration testing, privacy proxies, and runtime protections for AI agents. No specific vulnerability or exploit is described. The article emphasizes the growing need for dedicated AI security controls as AI systems become more integrated into security workflows.

The jsonschemavalid package version 4.26.0 on PyPI is a malicious clone of a legitimate package containing embedded reverse shell code. This reverse shell allows an attacker to execute arbitrary commands on the victim's machine. The published malicious version connects to a private IP address, indicating it may not have been fully weaponized at the time of discovery. There is no known exploit in the wild, and no official patch or remediation guidance is provided.

The new OMB logging directive raises the bar on log collection and explicitly ties every maturity milestone to how well agencies know what’s on their networks. Learn why asset visibility is the first problem to solve. Key takeaways M-26-14 rescinds M-21-31 and replaces blanket data-retention mandates with a five-element logging maturity model (levels 0-4) that agencies must progress through on a strict timeline after CISA publishes the logging reference architecture (LRA). Every maturity level is gated by inventory visibility. Specifically, agencies must demonstrate 70%, 80%, 90%, and 95% IT/OT/IoT asset capture at levels 1 through 4, respectively. After all, you can’t claim log coverage for assets you haven’t discovered. OT and IoT devices are explicitly in scope, including systems without native logging capability. This inclusion makes passive asset discovery tools a necessity rather than an add-on. The clock starts when CISA publishes the LRA within 90 days of the memo. Agencies that close asset-inventory gaps now will be positioned to hit the required deadlines, such as reaching level 1 in 120 days and level 3 in 321 days. You can’t log what you can’t see, and you can’t measure logging maturity against an incomplete inventory On May 22, the U.S. Office of Management and Budget (OMB) Director Russell Vought issued Memorandum M-26-14 , titled “Ensuring Effective and Efficient Agency Logging and Network Visibility to Defend Against Evolving Cyber Threats.” The directive rescinds M-21-31 and replaces it with a risk-based, prioritized logging framework designed to be both operationally achievable and aligned with today’s threat landscape. For federal cybersecurity leaders, M-26-14 represents a meaningful shift away from blanket data retention mandates and toward measurable, outcome-driven logging maturity. But hidden within its requirements is a foundational dependency that many agencies will need to address before their logging investments can deliver results: complete asset visibility . What M-26-14 requires, and why it’s different from M-21-31 The memorandum organizes logging around two objectives: Continuous event monitoring (CEM): Real-time log ingestion, anomaly detection, and SOC-driven response. Threat hunting, investigation, response, and forensics (THIRF): Centralized retrieval of historical log data to support post-compromise analysis and recovery. Agencies must achieve these objectives across all information systems, explicitly including internet-of-things (IoT) devices and operational technology (OT) systems, whether owned, operated, or managed by third parties. The memo also establishes a logging maturity model with five levels (0–4) that agencies must progress through on a defined timeline, with milestones measured across five elements: Inventory visibility : What percentage of IT/OT/IoT assets are captured in centralized hardware asset management (HWAM)/ software asset management (SWAM) inventories? Collection coverage : Are logs searchable and retrievable for those assets? Collection operations : Do logs generate actionable, tuned alerts? Data retention : Are logs retained for 6 months (searchable) and 12 months (retrievable)? Log management : Are logs encrypted, access-controlled, and properly retired? Agencies must reach level 1 (Basic) within 120 days, level 2 (Intermediate) within 180 days, and level 3 (Advanced) within 320 days of CISA publishing the logging reference architecture (LRA). A critical detail in the maturity model’s design: Overall maturity is calculated based on the lowest watermark across all five elements ( Appendix C footnote 8 ). For example, an agency that achieves level 3 in collection coverage but only level 1 in inventory visibility gets an overall rating of level 1. There is no averaging. This lowest-watermark principle makes inventory completeness the single most consequential element to address first. The denominator problem: Why incomplete inventories break the maturity model Look closely at the maturity model and a pattern emerges: Inventory completeness gates every level . Level 1 requires 70% of IT/OT/IoT assets captured in a centralized inventory Level 2 requires 80% Level 3 requires 90% Level 4 (Optimal) requires 95% The expansive scope of this OMB mandate — spanning on-premises IT, cloud workloads, identity providers, OT, and IoT — creates an immediate challenge: the denominator problem. Because log collection is measured as a percentage of your total inventory, you can’t claim 80% coverage if you only know about 60% of your assets. This operational gap is typically driven by administrative silos, air-gapped networks, and legacy OT/IoT environments that lack native logging or are unsafe to actively scan. Ultimately, managing visibility across this massive footprint comes down to one simple truth: You can’t write a logging plan for assets you haven’t discovered. How Tenable maps to M-26-14’s requirements Tenable has been embedded in the federal cybersecurity ecosystem as an a pproved continuous diagnostics and mitigation (CDM) vendor whose technology acts as the vulnerability management backbone for hundreds of civilian agencies, and increasingly as the platform that unifies visibility across IT, OT, and cloud attack surfaces. With M-26-14’s asset inventory requirements front and center, the foundation that Tenable’s technology provides is directly relevant to compliance milestones agencies must now achieve. The mapping below shows how Tenable capabilities correspond to M-26-14’s five maturity elements. -- Ground truth for the maturity model: Authoritative asset inventory Tenable One Vulnerability Management and Tenable One OT Exposure provide continuous, comprehensive asset discovery across traditional IT, operational technology, and IoT devices. This inventory serves as the ground truth for agencies to measure their maturity model progress, the denominator against which log collection coverage is calculated. -- Already CDM-connected: How Tenable accelerates HWAM/SWAM compliance M-26-14 explicitly directs agencies to use CDM, HWAM, and SWAM data to validate log coverage ( Appendix B, Requirement 4 ). As an established primary data source for federal CDM dashboards, Tenable eliminates the need for new data collection by pre-packing and reporting the inventory details M-26-14 requires. -- The Tenable solution: A phased approach to full visibility Standard IT scanners can crash fragile OT equipment like programmable logic controllers (PLCs). To meet M-26-14 requirements safely, Tenable offers a tiered approach: Phase 1: Baseline (Level 1): If you’re starting from scratch, use the OT Recon scan policy in Tenable Security Center or Tenable One Vulnerability Management. It uses “Safe Active Querying” with native industrial protocols to discover hardware and firmware details without downtime, helping you reach the 70% Level 1 baseline. Phase 2: Optimal Maturity (Level 4): To hit the 95% asset visibility threshold requiring daily updates, deploy Tenable One OT Exposure. By combining passive network monitoring with safe active querying, you gain persistent, real-time visibility into the deepest parts of the industrial network, bridging the gap to Level 4 maturity. -- From inventory to zero trust: Connecting visibility to the CISA Zero Trust Maturity Model Appendix A requires the LRA to align with CISA’s Zero Trust Maturity Model , which defines visibility and analytics as a cross-cutting capability enabling all five zero-trust pillars. The Tenable One Exposure Management Platform provides continuous attack surface visibility and risk quantification that feeds directly into z ero trust analytics, connecting vulnerability, identity, and configuration data into a unified exposure view. -- Beyond log retrieval: Vulnerability history as forensic evidence When investigating a compromise, security operations center (SOC) analysts need more than logs; they need to know which vulnerabilities existed on affected assets at the time of the incident. Tenable’s scan history and vulnerability timeline provide the forensic context required by Appendix B ( items j–k ): determining attack vectors, lateral movement paths, and root-cause analysis. -- AI-driven prioritization: Focusing logging resources where risk is highest Appendix A explicitly states that the LRA will address using AI to enhance CEM and THIRF capabilities. Tenable Hexa AI and Vulnerability Priority Rating (VPR) deliver AI-driven risk context that helps agencies prioritize which assets and vulnerabilities demand the most urgent logging and monitoring attention, directly supporting the “risk-based, prioritized” philosophy of M-26-14. Beyond inventory: Prioritizing logging resources where threat intelligence risk is highest Establishing an authoritative asset inventory provides the necessary compliance foundation, but it immediately introduces an operational challenge: once an agency uncovers thousands of previously unmanaged IT, OT, and IoT assets, where should security teams begin deploying limited logging resources? The same challenge exists across other parts of the modern attack surface. Cloud workloads, identity providers and directories, web applications, APIs, and containerized environments frequently operate in silos with incomplete inventories and inconsistent visibility. These assets can become equally unknown or poorly logged, creating additional blind spots that M-26-14’s risk-based, prioritized framework requires agencies to close. OMB M-26-14 explicitly shifts federal strategy away from legacy, blanket data -retention mandates and toward a “risk-based, prioritized” logging philosophy. However, the directive does not prescribe a formula for that prioritization. Leaving agencies to manually identify high-value assets (HVAs) and determine logging priorities across complex hybrid IT/OT/cloud/identity environments creates compliance bottlenecks. This is where asset discovery must transition into unified exposu

## Impact Three security vulnerabilities were identified in the OIDC Discovery client: 1. **Blind Server-Side Request Forgery (SSRF) via Cross-Host Redirects**: Fulcio uses an HTTP client to fetch OIDC discovery metadata (`/.well-known/openid-configuration`). Prior to this fix, if a configured issuer returned an HTTP redirect to a different host, the client followed it by default. This allowed a compromised or malicious issuer to redirect Fulcio's discovery requests to internal-only systems, resulting in blind SSRF. 2. **JWKS Substitution and Cache Poisoning**: Because cross-host redirects were permitted during OIDC discovery, an attacker could manipulate the discovery flow to return a malicious `jwks_uri` pointing to an attacker-controlled host. When Fulcio successfully initialized the provider and cached the resulting verifier in the verifier cache, it poisoned the cache with the attacker's verification keys. The attacker could then present signatures validated against the poisoned keys. 3. **Kubernetes ServiceAccount Token Leakage**: Fulcio mounts an in-cluster Kubernetes ServiceAccount token to authenticate OIDC discovery requests sent to the local control plane API server (`https://kubernetes.default.svc`). * **Cross-Host Redirects & JWKS**: The token was previously attached globally by the transport, leaking it to third-party hosts if the issuer performed a redirect or if the `jwks_uri` pointed to a different domain. * **Wildcard MetaIssuers**: If a wildcard `MetaIssuer` of type `kubernetes` (e.g., matching external EKS/GKE endpoints) was matched, and a local Kubernetes issuer was present in the config, the transport loaded and attached the local in-cluster ServiceAccount token to outbound requests sent to the external host. ## Patches The following mitigations have been applied: * **Blocked Cross-Host Redirects**: A custom callback is configured on all OIDC discovery HTTP clients to reject redirects that attempt to cross the original issuer's host boundary. * **Restricted Token Injection**: Updated the transport to only attach the ServiceAccount token when the outgoing request's host exactly matches the configured host of the issuer. * **Restricted Local Token Loading**: Constrained the loader to only load and wrap the transport with the local ServiceAccount token when the target issuer URL exactly matches the private local API server (`https://kubernetes.default.svc`). ## Workarounds None, upgrade to v1.8.6

The IPv6 Neighbor Discovery handlers in subsys/net/ip/ipv6_nbr.c (handle_ra_input, handle_ns_input, handle_na_input) used an incorrect boolean expression that combined the RFC 4861 validity checks with the ICMPv6 code check using the wrong operator precedence: the form was ((length/hop/source/target checks) && (icmp_hdr->code != 0)). Because every legitimate ND message carries ICMPv6 code 0, an attacker setting code == 0 (the normal value) caused the entire predicate to evaluate false, so the packet was never dropped and all of the other checks were silently skipped. The bypassed checks include the mandatory Hop Limit == 255 verification (which proves an ND packet originated on-link and was not forwarded) and, for Router Advertisements, the requirement that the source be a link-local address, as well as multicast-target sanity checks. As a result, an adjacent on-link attacker — and, because the Hop-Limit-255 guard is bypassed, potentially a remote/off-link attacker whose packets would otherwise be rejected — can have forged Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement messages accepted. A forged RA lets the attacker reconfigure the victim's default router, on-link prefixes (SLAAC), MTU, reachable/retransmit timers, and (with CONFIG_NET_IPV6_RA_RDNSS) DNS servers, while forged NS/NA enable neighbor-cache poisoning, enabling man-in-the-middle, traffic redirection, and denial of service. The flaw is an input-validation/authentication weakness rather than a memory-safety issue: the underlying packet-parsing primitives (net_pkt_get_data, net_pkt_read, net_pkt_skip) are independently bounds-safe and the validated length is the true buffer length, so skipping the length check causes no out-of-bounds access. The defect has existed since the logic was introduced in 2018 and shipped in all releases through v4.4.0; it is fixed by splitting the condition so any failing check drops the packet.

AI-driven tools are uncovering a large volume of previously unknown vulnerabilities in open source software, creating significant challenges for security teams. A coalition of companies, including Chainguard and others, is working to coordinate the discovery, reporting, and patching of these vulnerabilities. The rapid identification of bugs by advanced AI models has led to a surge in vulnerability disclosures, many affecting third-party open source components that organizations cannot directly patch. This situation complicates remediation efforts and increases the risk window before fixes are available upstream. Industry groups like Athena and Akrites aim to streamline vulnerability management and provide coordinated responses to mitigate the risks posed by this influx of AI-discovered flaws.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (910cc6eef707ac872daeb3a527e6dd9c75044ebb178f9eb48745f5cfd4123968) helpers.js defines a createLog() helper that base64-decodes a constant HASH_KEY to https://www.jsonkeeper.com/b/XVHGD (an anonymous JSON-paste host) and fetches the response, then passes data.data to a createLogger() function from the log-format-thread dependency. The destination URL is stored as a base64 literal to avoid plain-text discovery. However, the helper is never invoked from the package's main entry (index.js) in this version, and helpers.js itself contains broken code (an `import { req } from "request"` for an unused symbol, and a top-level `await` inside a non-async function) that would prevent the module from loading cleanly if it were required. The fetched content is also passed only to a logger formatter, not to eval/exec/Function/require — so even on the dead code path, the bytes are not executed as code. The combination of obfuscated URL + anonymous paste host + tampering shape is suspicious and inconsistent with a legitimate JSON-formatting helper, but the harmful path is not reached by a default require() of this package and there is no install-time lifecycle hook driving the fetch. ## Source: ghsa-malware (4b3b4e269246a3979e91e827093cc4161b3f4351957eae0d3f1ba80ae8a07502) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

bt_sdp_parse_attribute() in subsys/bluetooth/host/classic/sdp.c validated only that the SDP record buffer held the type-marker byte plus the 2-byte attribute ID (a check of buf->len < 3) but then read a fourth byte, the data-element descriptor (type), via net_buf_simple_pull_u8(). Because net_buf_simple_pull_u8() dereferences buf->data[0] before its only bounds guard (an __ASSERT_NO_MSG that compiles out when CONFIG_ASSERT is disabled, the production default), a record of exactly three bytes (0x09 followed by a 2-byte attribute ID) causes a one-byte read past the end of the logical buffer. The parser is reachable from inbound, remote-controlled data: a Bluetooth BR/EDR peer acting as an SDP server returns discovery-response records that are stored verbatim in the client receive buffer and parsed via the public bt_sdp_get_attr()/bt_sdp_has_attr()/bt_sdp_record_parse() helpers. The over-read is bounded to a single byte that is used only as an internal length selector and is never leaked to the attacker; subsequent length checks then reject the malformed record. Realistic impact is therefore limited to an edge-case denial of service (a fault only if the record ends exactly at a mapped-memory boundary, or a deterministic assert panic when CONFIG_ASSERT=y). Affects Zephyr v4.3.0 and v4.4.0; fixed by adding sizeof(type) to the length check.

A massive data leak exposed approximately 24 billion stolen credentials collected from various sources including infostealer logs, Telegram cybercrime channels, and breach compilations. The data included usernames, email addresses, plaintext passwords, and associated service URLs. The leak was discovered in an exposed Elasticsearch cluster containing over 8.3 terabytes of data. The database was taken offline shortly after discovery, limiting further investigation. The exposed credentials put billions of accounts at risk of takeover, especially those without multi-factor authentication enabled. The data owner appeared to actively update the collection with recent breach information. No specific software versions are affected as this is a data breach event rather than a software vulnerability.

This report covers Accenture's acquisition of a majority stake in Dragos and full acquisition of runZero and NetRise, valued at approximately $4.1 billion. The acquisitions aim to enhance Accenture's operational technology (OT) cybersecurity capabilities by combining Dragos' OT threat detection platform, runZero's asset discovery and attack surface intelligence, and NetRise's firmware analysis and supply chain visibility. The deal is positioned as a strategic expansion in the industrial cybersecurity market and is expected to close in late 2026. No specific security vulnerabilities or threats are described in this announcement.

Steeltoe.Discovery.Eureka versions prior to 3.4.0 and 4.2.0 improperly handle the DataCenterInfo.FromJson method by throwing an exception for the valid 'Netflix' data center name, which is defined in the Java Eureka specification. This causes the local service registry to become permanently empty or stale due to swallowed exceptions during cache refresh. The issue is patched in versions 3.4.0 and 4.2.0. If upgrading immediately is not possible, removing unsupported DataCenterInfo.name values from the registry is recommended.