Threat Intelligence Database
Comprehensive database of the latest cyber threats affecting organizations worldwide. Filter and search to find specific threat intelligence relevant to your organization.
Stop chasing alerts. Route them.
Start free, then upgrade once to turn Radar into an automated delivery engine for your security stack.
Custom feeds / Automations: email, Slack, webhooks, SIEM/MISP / API access (baseline limits)
API access activates after upgrading in Console -> Billing.
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.
Filter Threats
Narrow down the results by type, severity, or affected countries
Search Results: "443"
Click on any threat for detailed analysis and mitigation recommendations
--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (d10f01e2954dde5faac23074d02bb989f22d0dcb78be82c1c4417531fef8b859) The package ships a bundled Node script pyservercheck/js/main.js whose visible top half is a healthcheck stub matching the README, followed by a long run of tab whitespace and a trailing eval(atob('...')) that decodes to a two-stage loader. The decoded loader queries public Ethereum RPC endpoints (eth.blockscout.com, 1rpc.io/eth, eth.drpc.org, ethereum-rpc.publicnode.com, eth-mainnet.public.blastapi.io) for the latest transaction from the hardcoded sender 0xa322E5f3D311D3080e6f0121063e9aDC2490Ef1a, extracts an IPv4 pair from the tx `to` field, fetches XOR-obfuscated stage-2 code from http://<decoded-ip>:443/0x/cls and /0x/ls, eval()s it, and re-launches it via a detached `spawn('node', ['-e', <code>])`. Execution is wired to two auto-triggers: pyproject.toml overrides setuptools `build_py` and `develop` with pyservercheck._setup_cmd.BuildPy/Develop, whose `run()` calls _run_main_js_now() -> subprocess.run(['node', main.js]) during `pip install` / `pip install -e.`; and BuildPy also writes a `pyservercheck.pth` file containing `import pyservercheck._hooks; pyservercheck._hooks.ensure_once()`, which Python auto-executes at every interpreter startup, invoking run_js() again. The `.main_js_ran` marker is advisory and can be removed to force re-execution. The C2 destination is rotatable by publishing a new Ethereum transaction from the sender address, so the fetched payload is fully attacker-controlled at each run. ## Source: kam193 (4b365b9df06973db4f112bdbf2ad704dcc91c1b7b3eaceddb06a8e884c3f760a) Package embeds obfuscated, JS-based malware downloading further remote stages. The code is triggered during building the package and on every Python startup (via PTH file). The next-stage IP is delivered via a blockchain. The payload and embedded IoCs are consistent with campaigns attributed to Lazarus APT/PolinRider. --- Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers. Campaign: 2026-08-pybitjs Reasons (based on the campaign): - obfuscation - Downloads and executes a remote malicious script. - malware - abuses-pth - c2-in-blockchain Join the discussion | GCVE Database | 08/31/2026, 05:02:04 UTC Added: 08/31/2026, 15:42:54 UTC |
In the Linux kernel, the following vulnerability has been resolved: debugobjects: Plug race against a concurrent OOM disable syzbot reported a puzzling splat: WARNING: kernel/time/hrtimer.c:443 at stub_timer+0xa/0x20 stub_timer() is installed as timer callback function in hrtimer_fixup_assert_init(), which is invoked when debug_object_assert_init() can't find a shadow object. In that case debug objects emits a warning about it before invoking the fixup. Though the provided console log lacks this warning and instead has the following a few seconds before the splat: ODEBUG: Out of memory. ODEBUG disabled So the object was looked up in debug_object_assert_init() and the lookup failed due a concurrent out of memory situation which disabled debug objects and freed the shadow objects: debug_object_assert_init() if (!debug_objects_enabled) return; obj = alloc(); if (!obj) { // Out of memory debug_objects_enabled = false; free_objects(); obj = lookup_or_alloc(); // The lookup failed because the other side // removed the objects, so this returns // an error code as the object in question // is not statically initialized if (!IS_ERR_OR_NULL(obj)) return; if (!obj) { debug_oom(); return; } print(...) if (!debug_objects_enabled) return; fixup(...) The debug object splat is skipped because debug_objects_enabled is false, but the fixup callback is invoked unconditionally, which makes the timer disfunctional. This is only a problem in debug_object_assert_init() and debug_object_activate() as both have to handle statically initialized objects and therefore must handle the error pointer return case gracefully. All other places only handle the found/not found case and the NULL pointer return is a signal for OOM. Otherwise they get a valid shadow object. Plug the hole by checking whether debug objects are still enabled before invoking the print and fixup function in those two places. Join the discussion | GCVE Database | 08/10/2026, 12:17:00 UTC Added: 08/10/2026, 15:39:48 UTC |
## Summary There is a medium severity vulnerability in Traefik's ForwardAuth middleware. Even when configured with `trustForwardHeader: false`, Traefik derives the `X-Forwarded-Port` header sent to the authentication service from the original incoming request instead of the sanitized forwarded request. As a result, an unauthenticated remote attacker can inject an `X-Forwarded-Proto: https` header over a plain HTTP connection and cause Traefik to forward `X-Forwarded-Port: 443` to the auth service, bypassing port-based authorization checks. This is a regression of the incomplete fix for GHSA-6384-m2mw-rf54, which addressed the `X-Forwarded-Proto` and `X-Forwarded-Prefix` spoofing vectors but missed the `X-Forwarded-Port` vector. ## Patches - https://github.com/traefik/traefik/releases/tag/v2.11.51 - https://github.com/traefik/traefik/releases/tag/v3.6.22 - https://github.com/traefik/traefik/releases/tag/v3.7.6 ## For more information If you have any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues). <details> <summary>Original Description</summary> ### Summary The ForwardAuth middleware, even when configured with `trustForwardHeader: false`, still derives the `X-Forwarded-Port` header sent to the authentication service by reading the **attacker-controlled** `X-Forwarded-Proto` header from the original incoming request. This allows an unauthenticated remote attacker to cause Traefik to forward `X-Forwarded-Port: 443` to the auth service on a plain HTTP connection, creating an inconsistency that can bypass port-based authorization checks. ### Details The fix introduced in commit `5e1de2258` (released as part of the April 2026 security advisory GHSA-6384-m2mw-rf54) correctly strips all X-Forwarded-* headers from the forwarded auth request when `trustForwardHeader=false`, and reconstructs `X-Forwarded-Proto` from the actual TLS state of the connection (`req.TLS`). However, the reconstruction of `X-Forwarded-Port` is delegated to the helper `forwardedPort(req)` which receives the **original request** (`req`) rather than the sanitized forward request (`forwardReq`): ```go // pkg/middlewares/auth/forward.go – writeHeader() if !trustForwardHeader { forwardedheaders.DeleteXForwardedHeaders(forwardReq.Header) // strips all X-Fwd-* from forwardReq } // ... if _, ok := forwardReq.Header[forwardedheaders.XForwardedPort]; !ok { forwardReq.Header.Set(forwardedheaders.XForwardedPort, forwardedPort(req)) // ← req = ORIGINAL } // pkg/middlewares/auth/forward.go – forwardedPort() func forwardedPort(req *http.Request) string { if _, port, err := net.SplitHostPort(req.Host); err == nil && port != "" { return port } // Reads attacker-controlled header on the ORIGINAL request: if req.Header.Get(forwardedheaders.XForwardedProto) == "https" || ... { return "443" } if req.TLS != nil { return "443" } return "80" } Result when trustForwardHeader=false and attacker sends X-Forwarded-Proto: https on a plain HTTP connection: ┌──────────────────────────────────┬──────────┬────────┐ │ Header forwarded to auth service │ Expected │ Actual │ ├──────────────────────────────────┼──────────┼────────┤ │ X-Forwarded-Proto │ http │ http ✓ │ ├──────────────────────────────────┼──────────┼────────┤ │ X-Forwarded-Port │ 80 │ 443 ✗ │ └──────────────────────────────────┴──────────┴────────┘ ``` The inconsistency between Proto=http and Port=443 is exploitable against any authentication service that gates access based on X-Forwarded-Port. ### PoC Traefik configuration: ```http: middlewares: my-auth: forwardAuth: address: "http://auth-service/" trustForwardHeader: false # security setting, but still bypassable routers: api: rule: "PathPrefix(`/api`)" middlewares: - my-auth service: backend Auth service logic (example victim): # auth-service checks: only port 443 requests are considered "secure" port = request.headers.get("X-Forwarded-Port", "80") proto = request.headers.get("X-Forwarded-Proto", "http") if port == "443": return 200 # grant access return 403 ``` Attack: Plain HTTP connection, no TLS – but spoofs port 443 curl -H "X-Forwarded-Proto: https" http://traefik.example.com/api/admin Auth service receives X-Forwarded-Port: 443 → grants access Verification: Enable Traefik debug logging and observe X-Forwarded-Port: 443 in the auth request while the connection is plain HTTP. ### Impact Any deployment using the ForwardAuth middleware with trustForwardHeader: false where the downstream authentication service uses X-Forwarded-Port to make authorization decisions is vulnerable to privilege escalation. An unauthenticated attacker can bypass port-based s Join the discussion | GCVE Database | 08/06/2026, 16:38:29 UTC Added: 08/06/2026, 18:16:02 UTC |
--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (45fa3b05e748470cdc08e19b2e86efb8a34c85f155e5972c1b0c0598c150a0bd) The package's fesm2022 ESM entry (declared as `module` in package.json and executed on `import` of the library) ends with a trailing `eval(atob('...'))` payload that, once decoded, requires `child_process`, `http`, `https`, and `zlib` via `\uXXXX`-escaped identifier strings to hide the imports from static scanners. The loader queries an Ethereum contract at `0xa322E5f3D311D3080e6f0121063e9aDC2490Ef1a` through `https://eth.blockscout.com/api` (with public RPC fallbacks `1rpc.io/eth`, `eth.drpc.org`, `ethereum-rpc.publicnode.com`, `eth-mainnet.public.blastapi.io`) to read attacker-controlled host/port values from contract storage, then reaches those hosts over HTTP at paths `http://${host}:443/0x/cls` and `http://${host}:443/0x/ls` and passes the returned bytes to `child_process.spawn`. This is an EtherHiding remote-code-execution channel: consuming the library in any Node context that evaluates the ESM (SSR, build tooling, dev servers, tests) triggers on-chain-directed download and execution of arbitrary attacker code. The loader is unrelated to the package's advertised checkout functionality, is appended after the legitimate `export { ZahlenModule,... }` bundle, and is base64+unicode-obfuscated — hallmarks of an injected supply-chain payload rather than package feature code. ## Source: ghsa-malware (a3a38f34dcb95f0e345748ebb65454acd70b9fef5253e93f63e74c87b5278f23) 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. Join the discussion | GCVE Database | 08/05/2026, 12:48:29 UTC Added: 08/05/2026, 15:31:17 UTC |
--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (d4b16f8f98ad89c1276884f96b2ef878d2c597356aa2194c7067d2d0bbda943f) build/index.js appends an eval(atob('...')) block that fires when the module is required. The decoded payload queries Ethereum JSON-RPC endpoints (eth.blockscout.com, 1rpc.io/eth, eth.drpc.org, blastapi.io) for transactions from a hardcoded attacker wallet (0xa322E5f3D311D3080e6f01210639aDC2490Ef1a), reconstructs an IPv4 address from the bytes of tx.to, then fetches http://<resolved-ip>:443/0x/cls and http://<resolved-ip>:443/0x/ls. The response body is XOR-decoded with a hardcoded key and executed via eval() and a detached spawn('node','-e',...) child process (detached:true, stdio:'ignore', windowsHide:true, unref()). The C2 endpoint is mutable — the attacker rotates it by publishing new on-chain transactions from the controlled wallet — giving persistent remote code execution on any machine that imports the library. All require targets, URLs, HTTP header/method names, and error strings in the appended region are written as \u00XX unicode escapes and wrapped in base64+atob+eval; the legitimate __exportStar re-exports above the appended block are plain text, so the sole obfuscated region is the loader. ## Source: ghsa-malware (cd595e257df7f4732d6451f4cb0203806490fb7226f8815b0c583cf860d3b3ce) 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. Join the discussion | GCVE Database | 08/05/2026, 12:37:21 UTC Added: 08/05/2026, 15:31:18 UTC |
--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (d260e32207d8cb161b0a72f1337a42c9755b9550a8eda1e70f0b4182273d476b) build/index.js (the package main) appends a hidden eval(atob('...')) block after the legitimate __exportStar boilerplate, separated by a long run of tab characters to push it off-screen in editors. On every require/import of the package, the decoded payload queries an Ethereum RPC/Blockscout endpoint for the latest transaction of the hardcoded EOA 0xa322E5f3D311D3080e6f0121063e9aDC2490Ef1a, interprets the 20-byte tx.to address as two encoded IPv4 addresses, and issues HTTP requests to http://<resolved-ip>:443/0x/cls and http://<resolved-ip>:443/0x/ls. The response carries a payload in the x-payload-b64 header that is XOR-decoded and then executed via spawn('node', ['-e', <decoded>], {detached: true, stdio: 'ignore', windowsHide: true}).unref(), launching a detached hidden Node process on the installer's machine. Module identifiers such as 'http', 'https', 'child_process', and 'spawn' are unicode-escaped (\u00XX) to further hide the behavior. The combination of on-chain C2 resolution (resistant to DNS/domain takedown), multi-layer obfuscation, and hidden detached process execution on import is a remote-code-execution supply-chain attack against any project that installs this version. ## Source: ghsa-malware (037f3ed4ca92b64733adaadc02c839d4fc180a4547c0a191cefb45a57e8833d5) 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. Join the discussion | GCVE Database | 08/05/2026, 12:34:43 UTC Added: 08/05/2026, 15:31:19 UTC |
--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (9bb27849cbb16840b019ef47d6a84627d61eb9d48df28da5a9bc1a208e1ff758) build/index.js appends an eval(atob(...)) block after the normal __exportStar section that decodes to an import-time loader. The loader resolves a C2 IP by reading an Ethereum transaction associated with wallet 0xa322E5f3D311D3080e6f0121063e9aDC2490Ef1a (via eth_getBlockByNumber), then issues HTTP requests to http://<derived-IP>:443/0x/cls and http://<derived-IP>:443/0x/ls with an x-payload-b64 header, XOR-decrypts the responses, and launches each decoded body through spawn('node', ['-e', <payload>], {detached: true, stdio: 'ignore', windowsHide: true}).unref(). Strings inside the payload (http, https, spawn, child_process, eth_getBlockByNumber, x-payload-b64) are written as \u#### unicode escapes to hide the behavior from casual review. The loader runs on any require/import of the package, giving the operator of the on-chain-designated host arbitrary, hidden, detached code execution on the installer's machine, with the C2 address rotatable via a new Ethereum transaction. ## Source: ghsa-malware (aacfc893117769583694bc71a02db63d49b37b36243c48e00fa492c68e6beb37) 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. Join the discussion | GCVE Database | 08/05/2026, 12:34:06 UTC Added: 08/05/2026, 15:31:19 UTC |
--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (1cf5662d7c8759acd7a9a541baddd3bf4787594fafcd38f8a4eaf27bbe57d558) build/index.js appends an eval(atob(...)) trailer after legitimate re-exports. On require, the decoded loader queries public Ethereum JSON-RPC endpoints for the latest transaction from the hardcoded address 0xa322E5f3D311D3080e6f0121063e9aDC2490Ef1a, decodes the 20-byte tx.to value into two IPv4 addresses, fetches an XOR-obfuscated JavaScript payload from http://<ip>:443/0x/cls and http://<ip>:443/0x/ls, decodes an x-payload-b64 response header, and executes the result via eval and a detached spawn('node', ['-e', payload]). Security-relevant identifiers (http, child_process, spawn, method and header strings) are written as \u00XX unicode escapes to hide the behavior. Any application that requires this package runs attacker-controlled code on the installer's machine, and the C2 destination can be rotated on-chain without republishing the package. Package metadata (empty author, empty description, scoped `<scope>/common` name) is consistent with an impostor common-utilities package. ## Source: ghsa-malware (db85c2c336b7b7965deef4783c3eddd656dbaf384c2c73b5d50167ef308fa5e9) 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. Join the discussion | GCVE Database | 08/05/2026, 12:33:01 UTC Added: 08/05/2026, 15:31:19 UTC |
--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (097440ff1155e4d840568cf0fc8502c00d43249340f0f301167a859fd34c9fe8) The package's main module contains a top-level block that runs on every require/import. It uses unicode-escape obfuscation (\uXXXX) to hide imports of Node built-ins including child_process (spawn), http, https, zlib, and url. The prelude resolves a command-and-control host by querying Ethereum blockchain state via https://eth.blockscout.com/api keyed off contract address 0xa322E5f3D311D3080e6f0121063e9aDC2490Ef1a (with a public ETH RPC fallback list), then polls http://<resolved-host>:443/0x/ls and /0x/cls on that host and feeds the retrieved tasks into child_process.spawn, giving a remote operator arbitrary command execution on any developer machine or CI runner that installs or imports the package. The prelude also stashes global.r=require and global.m=module so C2-delivered payloads can load additional Node built-ins without repeating the unicode-escaped require dance. The React checkout code shipped below the prelude is cover; the on-chain C2 resolution is a rotation mechanism that lets the operator move infrastructure without republishing the package. ## Source: ghsa-malware (e8ea4ffb2df60ad2438699518b35cd7acdf501aa0de47a10a479f4a523079b7f) 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. Join the discussion | GCVE Database | 08/05/2026, 12:27:22 UTC Added: 08/05/2026, 15:31:27 UTC |
--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (7e2ac6bf5ebc05e3dcf6a84122d0b10d5d5f36c5b4cec9f8d0b305d1b8125f47) build/index.js appends an eval(atob(...)) blob to the legitimate common-library exports, so the payload runs whenever any consumer require()s @rentwise/common. The decoded payload queries public Ethereum JSON-RPC nodes and eth.blockscout.com/api to fetch the latest transaction sent by the hardcoded wallet 0xa322E5f3D311D3080e6f0121063e9aDC2490Ef1a, reconstructs an IPv4 address from the transaction's tx.to field (bytes 0-3 as octets), then HTTP GETs http://<ip>:443/0x/cls and http://<ip>:443/0x/ls. The response body is XOR-decoded using the x-payload-b64 header, eval()'d in-process, and additionally spawned as a detached `node -e <payload>` child process with stdio:ignore and windowsHide. All strings (module names http/https/zlib/child_process, URLs, RPC method names) are \uXXXX-escaped inside the base64 blob to defeat static string matching. The blockchain-anchored C2 (EtherHiding pattern) lets the operator rotate infrastructure by broadcasting a new on-chain transaction. This grants arbitrary remote code execution on any host that installs and loads the package. ## Source: ghsa-malware (0bbef705c23f606ecd8e4257d3de3818a1e460136c9c3aa8a5aafa1b93c0585b) 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. Join the discussion | GCVE Database | 08/05/2026, 12:24:34 UTC Added: 08/05/2026, 15:31:28 UTC |
Showing 1 to 10 of 40 results