Search: nothing.this

Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to drain the fee-payer wallet, resulting in denial of service for legitimate clients. When the mpp Elixir library is configured as fee payer (fee_payer: true), the MPP.Methods.Tempo payment method co-signs and broadcasts a client-supplied EVM transaction without first validating that the client-supplied gas_limit is sufficient to complete the intended call. A malicious client can submit a signed transferWithMemo transaction with gas_limit deliberately set just below the amount required for successful execution. The server co-signs the transaction and broadcasts it via rpc_broadcast_sync. The transaction runs out of gas during EVM execution and reverts, but the fee-payer wallet is still charged for the burned gas while the client pays nothing and receives no resource. Repeated requests from one or more malicious clients drain the fee-payer wallet at near-zero cost to the attacker, ultimately preventing the server from sponsoring gas for legitimate payment requests. The wait_for_confirmation = false (optimistic) path is also affected: it invokes simulate_payment_call via eth_call, but that simulation omits the gas parameter and therefore does not catch out-of-gas conditions. This issue affects mpp: from 0.2.0 before 0.6.0.

### Summary A Clauster instance bound to a **non-loopback** address (e.g. `0.0.0.0` or a LAN IP) can serve the entire dashboard and its API **without any authentication** — even when the operator has configured a password — if `auth.enabled` is left at its default (`false`). The operator believes the instance is password-protected; in reality every request is served unauthenticated. ### Impact An unauthenticated attacker with network access to the instance gains full control of the dashboard: list projects, **spawn/stop `claude remote-control` bridges in any project directory**, edit `CLAUDE.md`, read bridge logs, and (where configured) clone repositories. Because bridges run Claude Code against the host's project directories, this is effectively remote code execution in those projects. Loopback (`127.0.0.1`) deployments need no auth by design and are **not** affected. ### Affected configurations All released versions (≤ 0.2.1) where **all** of the following hold: - `host` is a non-loopback address, **and** - `auth.password_required: true` and/or `auth.reverse_proxy.enabled: true` is set, **and** - `auth.enabled` is left at its default `false`. Docker deployments are affected: the image binds `0.0.0.0`, and the previously-documented `docker run` command did not set `auth.enabled`. ### Root cause Two layers checked different flags: - The runtime auth guard enforces authentication only when `config.auth.enabled` is true; when false it passes **every** request through unauthenticated. - The config validator, for a non-loopback bind, required only one of `auth.password_required` / `auth.reverse_proxy.enabled` / `auth.allow_unauthenticated_network` — **not** `auth.enabled`. So a config with a password but `enabled=false` validated, started, and enforced nothing. ### Proof of concept With `host: 0.0.0.0`, `auth.password_required: true`, a valid `auth.password_hash`, and `auth.enabled` unset: ``` curl http://<host>:7621/api/instances ``` returns `200` with the full instance list and **no credentials**. Setting `auth.enabled: true` returns `401`. ### Patches An upcoming patch release makes the config validator **fail closed**: a non-loopback bind is refused unless authentication is actually enforced — `auth.enabled: true` together with `auth.password_required` (+ a hash) or `auth.reverse_proxy.enabled`, or the explicit `auth.allow_unauthenticated_network` opt-out. The README, `clauster.yml.example`, and Docker docs were corrected to match. ### Workaround On any non-loopback deployment, set `auth.enabled: true` in `clauster.yml` (or `CLAUSTER_AUTH_ENABLED=true`) alongside your existing `auth.password_required` + hash (or reverse-proxy) settings. Alternatively, bind to loopback only and reach it via an SSH tunnel or a trusted authenticating reverse proxy. ### Credit Found during an internal security review.

### Summary `Project.AddFile`, `Project.EditFile`, `Project.RemoveFile`, and `Project.Edit` in `cmd/server/api/project/handler.go` accept a project or project-file row id from the JSON body and act on it without checking that the project belongs to the caller's namespace. The corresponding `model.ProjectFile.GetData` and `model.Project.GetData` queries filter only by row id. A user holding the `manager` role (or any role that includes the `FileSync` / `EditProject` permission) in their own namespace can read, write, or delete files in any project across the install, and can rewrite any project's git remote URL by submitting the foreign id in the body. The git-URL primitive escalates to RCE on the next deploy because `Edit` runs `git remote set-url` on the project's working tree. ### Affected `zhenorzz/goploy` `develop` HEAD as of 2026-05-27. Verified against the `zhenorzz/goploy:1.17.5` Docker image (`docker.io/zhenorzz/goploy@sha256:69d08e1d16d7a7167426c89456c4bcef8e077a16554a4067ff258fff26d5cd44`). The four handlers and the model lookups have been in this shape across the file API and project metadata API. ### Vulnerable code `cmd/server/api/project/handler.go::AddFile` (creates file under any project's directory; body controls `projectId`): ```go func (Project) AddFile(gp *server.Goploy) server.Response { type ReqData struct { ProjectID int64 `json:"projectId" validate:"required,gt=0"` Content string `json:"content" validate:"required"` Filename string `json:"filename" validate:"required"` } var reqData ReqData if err := gp.Decode(&reqData); err != nil { ... } filePath := path.Join(config.GetProjectFilePath(reqData.ProjectID), reqData.Filename) // ... os.Create(filePath); file.WriteString(reqData.Content) id, err := model.ProjectFile{ProjectID: reqData.ProjectID, Filename: reqData.Filename}.AddRow() } ``` `cmd/server/api/project/handler.go::EditFile` (overwrites file content; body controls file id, server derives project from the file row): ```go func (Project) EditFile(gp *server.Goploy) server.Response { type ReqData struct { ID int64 `json:"id" validate:"required,gt=0"` Content string `json:"content" validate:"required"` } var reqData ReqData if err := gp.Decode(&reqData); err != nil { ... } projectFileData, err := model.ProjectFile{ID: reqData.ID}.GetData() // ... os.Create(path.Join(config.GetProjectFilePath(projectFileData.ProjectID), projectFileData.Filename)) file.WriteString(reqData.Content) } ``` `cmd/server/api/project/handler.go::RemoveFile` (deletes file row + on-disk file by body id): ```go func (Project) RemoveFile(gp *server.Goploy) server.Response { type ReqData struct { ProjectFileID int64 `json:"projectFileId" validate:"required,gt=0"` } var reqData ReqData if err := gp.Decode(&reqData); err != nil { ... } projectFileData, err := model.ProjectFile{ID: reqData.ProjectFileID}.GetData() if err := os.Remove(path.Join(config.GetProjectFilePath(projectFileData.ProjectID), projectFileData.Filename)); err != nil { ... } } ``` `cmd/server/api/project/handler.go::Edit` (updates any project's metadata; on URL change runs `git remote set-url` in the project working tree): ```go func (Project) Edit(gp *server.Goploy) server.Response { // ... ReqData has ID, Name, URL, Branch, Script, etc. projectData, err := model.Project{ID: reqData.ID}.GetData() model.Project{ID: reqData.ID, Name: reqData.Name, URL: reqData.URL, ...}.EditRow() if reqData.URL != projectData.URL { srcPath := config.GetProjectPath(projectData.ID) cmd := exec.Command("git", "remote", "set-url", "origin", reqData.URL) cmd.Dir = srcPath } } ``` `internal/model/project_file.go::ProjectFile.GetData` filters only by row id, no namespace join: ```go func (pf ProjectFile) GetData() (ProjectFile, error) { err := sq. Select("id, project_id, filename, insert_time, update_time"). From(projectFileTable). Where(sq.Eq{"id": pf.ID}). ... } ``` `internal/server/route.go::Route.hasPermission` checks only namespace-level permission ids; nothing in the request flow verifies that the body-supplied project id belongs to `gp.Namespace.ID`: ```go func (r Route) hasPermission(permissionIDs map[int64]struct{}) error { if len(r.permissionIDs) == 0 { return nil } for _, permissionID := range r.permissionIDs { if _, ok := permissionIDs[permissionID]; ok { return nil } } return errors.New("no permission") } ``` ### Reachable Any logged-in user assigned the `manager` role in their own namespace can call `/project/addFile`, `/project/editFile`, `/project/removeFile`, and `/project/edit`. The seeded `manager` role (`role.id = 1`) is granted both `FileSync` (`permission.id = 68`) and `EditProject` (`permission.id = 17`) by `database/goploy.sql`. Multi-tenant deployments typically assign `manager` to each ten

Neo4jChatAgent passes LLM-generated Cypher queries straight to the Neo4j driver with no validation, no statement-type allowlist, and no opt-out gate. The query text is influenceable by prompt injection (direct user input or indirect content the agent reads back via RAG), so an attacker who can influence the prompt can read or destroy all graph data and, when APOC or dbms.security procedures are enabled on the server, achieve OS-command and filesystem access. This is the same defect class and threat model as the SQLChatAgent prompt-to-SQL-to-RCE issue fixed in version 0.63.0 (CVE-2026-25879); that fix did not extend to the neo4j module. ## Technical detail Untrusted-input to sink trace (reviewed on langroid HEAD b9df06f, v0.65.3): 1. Tool schemas accept raw query text from the LLM. `langroid/agent/special/neo4j/tools.py:4-9` (CypherRetrievalTool.cypher_query: str) and `:15-21` (CypherCreationTool.cypher_query: str). These tools are enabled unconditionally in `neo4j_chat_agent.py:412-419` (enable_message([GraphSchemaTool, CypherRetrievalTool, CypherCreationTool, DoneTool])). 2. Read path. `neo4j_chat_agent.py:300` cypher_retrieval_tool(msg) -> `:325` query = msg.cypher_query -> `:328` self.read_query(query) -> `:223` session.run(query, parameters). The LLM-controlled string is the first positional argument to session.run; parameters is None. No validation occurs between :325 and :223. 3. Write path. `neo4j_chat_agent.py:338` cypher_creation_tool(msg) -> `:348` query = msg.cypher_query -> `:351` self.write_query(query) -> `:276` session.write_transaction(lambda tx: tx.run(query, parameters)). The only inspection of the string (write_query :251-264) is a query.upper() substring test for CREATE/MERGE/CONSTRAINT/INDEX whose sole effect is setting self.config.database_created = True; it blocks nothing. A query such as `MATCH (n) DETACH DELETE n` (the same statement the built-in remove_database helper runs at :287-293) passes unrestricted. 4. Guarded-sibling contrast proving the incomplete fix. The SQLChatAgent, patched for the parent CVE, validates every query before execution. `langroid/agent/special/sql/sql_chat_agent.py:256` defines allow_dangerous_operations: bool = False (opt-in gate); `:618` _validate_query runs (a) a dangerous-pattern regex blocklist (_DANGEROUS_SQL_PATTERNS, :628-641), (b) a sqlglot statement-type allowlist defaulting to SELECT-only (:643-686), and (c) an AST-level dangerous-function blocklist (:687-704). run_query calls rejection = self._validate_query(query) at `:721` before executing. The neo4j read_query/write_query paths have no equivalent: a grep for _validate_query/allow_dangerous in neo4j_chat_agent.py returns nothing. The defense exists for SQL and is simply absent for Cypher, which is the definition of an incomplete fix for the same prompt-to-query-language injection class. ## Proof of concept (static, no third-party systems, no live Neo4j required) Step 1 (presence vs absence of the guard, one command): ``` grep -n "_validate_query\|allow_dangerous" langroid/agent/special/sql/sql_chat_agent.py # SQL: many hits (gate + validator + call site :721) grep -n "_validate_query\|allow_dangerous" langroid/agent/special/neo4j/neo4j_chat_agent.py # neo4j: ZERO hits ``` Step 2 (sink trace is direct, no interposed check): ``` read_query: msg.cypher_query (line 325) -> read_query(query) (328) -> session.run(query, parameters) (223) write_query: msg.cypher_query (348) -> write_query(query) (351) -> tx.run(query, parameters) (276) ``` The only string inspection (write_query 251-264) is a .upper() substring test that only sets database_created=True and rejects nothing. The asymmetry (validator + opt-out gate enforced on every SQL query at sql_chat_agent.py:721; nothing on either Cypher path) is the deterministic artifact: the same project, for the same injection class, guards one query language and not the other. A dynamic confirmation against an operator-owned disposable Neo4j (create a CSPRNG-marked node via cypher_creation_tool, read it back via cypher_retrieval_tool, then DETACH DELETE it) reproduces the read/write/destroy primitive without any third-party system. ## Impact An attacker who can influence the agent prompt (directly, or indirectly via content the agent reads back through RAG) controls the executed Cypher. Floor (no extra config, not contingent): unauthorized read of all graph data via cypher_retrieval_tool and full write/destroy (including MATCH (n) DETACH DELETE n) via cypher_creation_tool, plus the built-in LOAD CSV remote-fetch (SSRF) primitive. Ceiling (config-conditional, when APOC / dbms.security procedures are granted to the DB role, a common deployment): apoc.load.* (SSRF + remote/local file read), apoc.cypher.runFile / apoc.import.* / apoc.export.* (filesystem), and CALL dbms.* admin procedures, i.e. the Cypher analogue of the parent's COPY ... FROM PROGRAM RCE primitive. This mirrors the privileged-role contingency the parent advisory (CVE-2026-25879) accep

Improper Input Validation, Exposure of Sensitive Information to an Unauthorized Actor, Server-Side Request Forgery (SSRF) vulnerability in Apache Camel in Iggy component. The camel-iggy consumer mapped the user-headers of inbound Iggy messages into the Camel Exchange header map without applying any HeaderFilterStrategy (IggyFetchRecords copied the message user-headers straight into the Exchange). Because nothing blocked the Camel header namespace, an actor able to publish to the consumed Iggy stream/topic could set Camel-internal control headers - including CamelHttpUri (Exchange.HTTP_URI) - simply by supplying them as message user-headers. In a route where the Iggy consumer feeds a downstream HTTP producer, the injected CamelHttpUri redirects the server-side HTTP request to an attacker-chosen destination (server-side request forgery - for example to an internal service or a cloud metadata endpoint). In addition, the HTTP producer resolves Camel property placeholders on the resulting (attacker-controlled) URI, so placeholders embedded in the injected value - such as an environment-variable reference, an application property, or a vault reference - are resolved to their real values and sent to the attacker, disclosing environment variables, application properties and vault secrets. This issue affects Apache Camel: from 4.17.0 before 4.18.3, from 4.19.0 before 4.21.0. Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. The fix adds a dedicated IggyHeaderFilterStrategy (and a headerFilterStrategy endpoint option) that filters the Camel header namespace case-insensitively on inbound mapping, so externally-supplied Camel* / camel* headers are no longer copied into the Exchange. For deployments that cannot upgrade immediately, strip the Camel control headers from the inbound message before they reach any downstream producer (for example removeHeaders('Camel*') and removeHeaders('camel*') at the start of the route), restrict who can publish to the consumed Iggy stream/topic, and avoid bridging an untrusted consumer directly into an HTTP producer whose target URI can be driven from message headers.

Improper Input Validation, Exposure of Sensitive Information to an Unauthorized Actor, Server-Side Request Forgery (SSRF) vulnerability in Apache Camel in Atmosphere Websocket Component. The camel-atmosphere-websocket consumer mapped inbound WebSocket query parameters into the Camel Exchange header map without applying any HeaderFilterStrategy (WebsocketConsumer.sendEventNotification() iterates the query-string map collected in WebsocketConsumer.service() and copies each entry into the Exchange). Because nothing blocked the Camel header namespace, a client connecting to the WebSocket endpoint could set Camel-internal control headers - including CamelHttpUri (Exchange.HTTP_URI) - simply by supplying them as query parameters. In a route where the WebSocket consumer feeds a downstream HTTP producer, the injected CamelHttpUri redirects the server-side HTTP request to an attacker-chosen destination (server-side request forgery - for example to an internal service or a cloud metadata endpoint). In addition, the HTTP producer resolves Camel property placeholders on the resulting (attacker-controlled) URI, so placeholders embedded in the injected value - such as an environment-variable reference, an application property, or a vault reference - are resolved to their real values and sent to the attacker, disclosing environment variables, application properties and vault secrets. When the WebSocket endpoint is exposed without authentication, this is reachable by an unauthenticated remote attacker. This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0. Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. The fix makes the consumer apply the HeaderFilterStrategy it already inherits from the HTTP/servlet stack, filtering the Camel header namespace case-insensitively on inbound mapping, so externally-supplied Camel* / camel* headers are no longer copied into the Exchange. For deployments that cannot upgrade immediately, strip the Camel control headers from the inbound message before they reach any downstream producer (for example removeHeaders('Camel*') and removeHeaders('camel*') at the start of the route), require authentication on the WebSocket endpoint, and avoid bridging an untrusted consumer directly into an HTTP producer whose target URI can be driven from message headers.

Improper Input Validation, Exposure of Sensitive Information to an Unauthorized Actor, Server-Side Request Forgery (SSRF) vulnerability in Apache Camel in Vertx Websocket component. The camel-vertx-websocket consumer mapped inbound WebSocket query and path parameters into the Camel Exchange header map without applying any HeaderFilterStrategy (VertxWebsocketConsumer.populateExchangeHeaders()). Because nothing blocked the Camel header namespace, a client connecting to the WebSocket endpoint could set Camel-internal control headers - including CamelHttpUri (Exchange.HTTP_URI) - simply by supplying them as query parameters. In a route where the WebSocket consumer feeds a downstream HTTP producer, the injected CamelHttpUri redirects the server-side HTTP request to an attacker-chosen destination (server-side request forgery - for example to an internal service or a cloud metadata endpoint). In addition, the HTTP producer resolves Camel property placeholders on the resulting (attacker-controlled) URI, so placeholders embedded in the injected value - such as an environment-variable reference, an application property, or a vault reference - are resolved to their real values and sent to the attacker, disclosing environment variables, application properties and vault secrets. When the WebSocket endpoint is exposed without authentication, this is reachable by an unauthenticated remote attacker. This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0. Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. The fix makes the affected consumers apply a HeaderFilterStrategy that filters the Camel header namespace case-insensitively on inbound mapping, so externally-supplied Camel* / camel* headers are no longer copied into the Exchange. For deployments that cannot upgrade immediately, strip the Camel control headers from the inbound message before they reach any downstream producer (for example removeHeaders('Camel*') and removeHeaders('camel*') at the start of the route), require authentication on the WebSocket endpoint, and avoid bridging an untrusted consumer directly into an HTTP producer whose target URI can be driven from message headers.

zredis-typed is a malicious npm package and part of the multi-wave "forge-jsx" cross-platform RAT campaign (Wave 4). It was published by npm account 'donimique' (donimiqueakers@gmail.com). The package.json description ('Node.js integration layer for Autodesk Forge') and the bundled README.md (literally titled "# forge-jsx") do not match the package name or the shipped code. On npm install the declared postinstall chain (postinstall-clipboard-event.mjs, ensure-dist.mjs, postinstall-durable-materialize.mjs, postinstall-bootstrap.mjs, postinstall-agent.mjs) runs scripts/postinstall-agent.mjs, which spawns dist/cli-agent.js as a detached, window-hidden background process. The agent connects over WebSocket to a command-and-control relay whose host, ports and default password are stored as an AES-256-GCM blob in dist/deploymentCipherData.js and decrypted at runtime by XOR-reconstructing a 32-byte key from two halves embedded in dist/deploymentDefaults.js. The decrypted C2 configuration is publicHost 212.193.3.61, relayPort 9877 (WebSocket relay), apiPort 8765 (HTTP API), default password 'secret'. Postinstall also registers OS-level autostart (Windows Run key, macOS LaunchAgent, Linux systemd/XDG autostart; service name forge-js-worker) pointing at a durable copy of the agent stored in a hidden '.forge-jsxy' directory under the platform application-data folder, so the implant survives removal of the npm package. Once running it performs credential-grade theft: dist/secretScan/agentStartupAudit.js walks the filesystem for BIP39-checksum-valid mnemonics, secp256k1/WIF private keys and BIP32 extended keys (xprv/tprv/zprv); dist/chromiumExtensionDbHarvest.js enumerates Chromium/Edge/Brave/Vivaldi/Yandex/Opera profiles across Windows, macOS and Linux and copies extension LevelDB stores (including MetaMask/Phantom-shaped wallet stores); harvested data is uploaded to the Hugging Face Hub using an embedded hf_ write token (dist/hfCredentials.js) or delivered via the relay; dist/hostInventorySend.js POSTs host inventory (hostname/platform/node/OS) to the relay and dist/discordRelayUpload.js forwards agent-side PNG screenshots to per-client Discord channels. This is the first wave of the campaign to ship rotated AES key material (new DEPLOYMENT_KEY_A/KEY_B/MASK_A/MASK_B byte arrays, hex 12335cede9edad1edbce89fd3ef0836c8edd3778e48f3f38f2330198ec8b1eb0), verified byte-identical across the four donimique-account packages (zod-pino434, zod-pino444, zredis-typed, pinokio-redis) — a single shared build. C2 212.193.3.61 (AS206216, Advin Services LLC, Nurnberg DE) is reused from the Wave 3 pino-zod/zod-pino IP rotation. The campaign is definitively linked by shared C2 infrastructure, the hardcoded '.forge-jsxy' durable directory, the dist/deploymentCipherData.js + dist/deploymentDefaults.js XOR-key fingerprint, and the '# forge-jsx' README tell that spans multiple package names and npm accounts. Only one version of zredis-typed (1.0.127) exists; all versions are malicious. Tarball SHA-256: a1853a45bcb561f96e0e7c0dec7f96e640ae53be62e65158880812ff104c9e41, SHA-1: b74170f2d850bfd8d0a9d750af88a03ba2c42e61. --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (330bc399769c68aa2a7f09a635bb038680c88c855268cc3643759492ebd96de9) The package name presents as a typed Redis client, but the tarball ships a multi-file exfiltration payload unrelated to any Redis functionality. `dist/discordRelayUpload.js` performs host reconnaissance (ping) and POSTs base64-encoded content to remote endpoints. `dist/relayServer.js` similarly runs ping-based host probing. `dist/secretScan/agentStartupAudit.js` fetches attacker-controlled URLs on huggingface.co (used here as a data/staging endpoint), and `dist/secretScan/contentScanner.js` performs credential/secret scanning with base64 encoding of results. `dist/hfCredentials.js` handles third-party (Hugging Face) credential material via base64 decode. `dist/deploymentDefaults.js` and `scripts/encode-deployment.mjs` encode/decode deployment payloads via base64. `scripts/postinstall-agent.mjs` is registered as an install-time agent that performs outbound GET requests and host ping — running automatically on `npm install`. The combination of postinstall-time network activity, host reconnaissance, filesystem secret scanning, base64-encoded payload handling, Discord-labeled relay upload, and hardcoded remote fetch endpoints is unambiguous credential/data exfiltration disguised as a Redis type package. Nothing in the shipped modules implements a Redis client. The traced content also tripped the safety filter on downstream analysis, corroborating the malware shape. ## Source: ghsa-malware (73b8d51428450de7f67cb29aa402a94aefd62bdcf03e4f0eee43c554576eec2e) 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,

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (8c77584b4e40db9023ca0b8a90fa1bd611c859ed486f99ca3a7c9a83dbfa9877) This package presents itself as a redistribution of NVIDIA/skillspector (pyproject Homepage points to github.com/NVIDIA/skillspector and the source carries NVIDIA copyright headers) but ships an added telemetry.py module whose own header notes it is not part of the upstream project. telemetry.py hardcodes DEFAULT_TELEMETRY_ENDPOINT = "https://livekit-agents.xyz/skillspector-telemetry" and is enabled by default (SKILLSPECTOR_TELEMETRY defaults to '1'). On every `skillspector` CLI invocation, an @app.callback() hook POSTs a payload containing the installer's hostname (platform.node), username (getpass.getuser), current working directory (os.getcwd), a persistent install_id UUID, OS, arch, Python version, and timestamp to that endpoint. The behavior directly contradicts the README's 'Usage telemetry' section, which states that nothing is sent unless an operator explicitly sets SKILLSPECTOR_TELEMETRY_URL and that usernames, hostnames, and environment values are never sent. The destination domain is unrelated to the declared publisher (NVIDIA). Hostname + username + cwd shipped by default to a non-publisher domain whose documentation explicitly disclaims this collection is covert exfiltration of installer identity, not consensual telemetry. ## Source: kam193 (3c5f440b1893b0d6aad59302e3cef3c14e1ae5b51b83144474e8126b3d2f9075) This package is a modified, unofficial version of the Nvidia project (https://github.com/NVIDIA/skillspector). The modification is disguised as telemetry. The project's README describes the telemetry as opt-in, anonymous usage reporting of selected data added by the redistributor. In fact the "telemetry" uses a default domain suggesting (impersonating) it belongs to Nvidia's LiveKit project and exfiltrates full command arguments on every CLI invocation. --- Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers. Campaign: 2026-06-skillspector Reasons (based on the campaign): - The package contains code to exfiltrate basic data from the system, like IP or username. It has a limited risk. - exfiltration-generic - dependency-confusion - clones-real-package

### Summary The `ExpressionDepthLimit` parser guard in Scriban does not actually stop parsing — it only logs a non-fatal error and lets recursive descent continue. As a result, a template containing a deeply nested expression (parentheses, array initializers, object initializers, or unary operators) drives the recursive-descent parser into a native stack overflow. The resulting `StackOverflowException` is **uncatchable** in .NET and **immediately terminates the host process**. Any application that parses an attacker-influenced template — or that passes attacker-controlled strings to `object.eval` / `object.eval_template` — can be crashed by a single small request (roughly an 8 KB payload). This is a denial-of-service. It affects both Scriban-native (`Template.Parse`) and Liquid (`Template.ParseLiquid`) syntax modes, which share the same expression parser. This re-opens two advisories that were reported as fixed: **GHSA-wgh7-7m3c-fx25** ("Uncontrolled recursion in parser → StackOverflow", reported fixed in 6.6.0) and **GHSA-p6q4-fgr8-vx4p** ("StackOverflow via nested array initializers bypasses ExpressionDepthLimit", reported fixed in 7.0.0). Both fixes are incomplete: the limit they rely on never halts recursion. **All releases 6.6.0 through 7.2.0 (current) are affected.** ### Details The depth guard is `EnterExpression()` in `src/Scriban/Parsing/Parser.Expressions.cs`: ```csharp // src/Scriban/Parsing/Parser.Expressions.cs:1209-1218 private void EnterExpression() { _expressionDepth++; var limit = Options.ExpressionDepthLimit; if (limit > 0 && !_isExpressionDepthLimitReached && _expressionDepth > limit) { LogError(GetSpanForToken(Previous), $"The statement depth limit `{limit}` was reached when parsing this statement"); _isExpressionDepthLimitReached = true; } } ``` When the limit is exceeded it calls `LogError(...)` and sets a flag. It does **not** throw, does **not** return a sentinel, and does **not** unwind the parse. `LogError` here uses the default `isFatal: false`, so it merely appends a message and sets `HasErrors` — parsing proceeds: ```csharp // src/Scriban/Parsing/Parser.cs:476-488 private void Log(LogMessage logMessage, bool isFatal = false) { Messages.Add(logMessage); if (logMessage.Type == ParserMessageType.Error) { HasErrors = true; if (isFatal) _hasFatalError = true; // not set on the depth-limit path } } ``` The flag `_isExpressionDepthLimitReached` is consulted **only** to avoid logging the same error more than once — no code path uses it to stop descending. Confirmed by full-repo search (`grep -rn "_isExpressionDepthLimitReached" src/`): it appears in exactly four places — the field declaration (`Parser.cs:40`), a reset to `false` (`Parser.cs:106`), and within `EnterExpression` the dedup test (`Parser.Expressions.cs:1213`) and its assignment to `true` (`:1216`). The only *read* is the dedup test on line 1213; nothing else reads it. `ParseExpression` calls `EnterExpression()` and then continues straight into the token switch with no flag check: ```csharp // src/Scriban/Parsing/Parser.Expressions.cs:113 + 181-182 EnterExpression(); try { ... case TokenType.OpenParen: leftOperand = ParseParenthesis(); // recurses back into ParseExpression ``` ```csharp // src/Scriban/Parsing/Parser.Expressions.cs:984-1001 private ScriptExpression ParseParenthesis() { var expression = Open<ScriptNestedExpression>(); ExpectAndParseTokenTo(expression.OpenParen, TokenType.OpenParen); expression.Expression = ExpectAndParseExpression(expression); // -> ParseExpression -> ParseParenthesis -> ... ... } ``` Both `Template.Parse` (Scriban-native) and `Template.ParseLiquid` (Liquid-compatibility) front-ends share this same expression parser, so both entry points are affected. So for input nested N levels deep, the parser recurses N levels deep regardless of `ExpressionDepthLimit`. There is no `RuntimeHelpers.EnsureSufficientExecutionStack()` call and no absolute recursion cap anywhere in the parser. Once the native thread stack is exhausted, the runtime raises `StackOverflowException`, which .NET does not allow to be caught and which tears down the entire process. The number of nesting levels required to overflow depends on the platform's thread-stack size (empirically around 4,000 levels on a default 1 MB stack); it is not a configurable mitigation. The same defective guard is what makes the array-initializer fix for GHSA-p6q4-fgr8-vx4p ineffective: `ParseArrayInitializer` was wrapped in `EnterExpression()/LeaveExpression()`, but because `EnterExpression()` only logs, the array path still overflows. The existing regression tests only assert `HasErrors == true` at a nesting depth of ~20 with a limit of 10 (`src/Scriban.Tests/TestParser.cs`); they never use a depth large enough to overflow the stack, so they pass while the protection does nothing against the actual DoS. **Runtime reachability without

In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ct: Only release RCU read lock after ct_ft When looking up a flow table in act_ct in tcf_ct_flow_table_get(), rhashtable_lookup_fast() internally opens and closes an RCU read critical section before returning ct_ft. The tcf_ct_flow_table_cleanup_work() can complete before refcount_inc_not_zero() is invoked on the returned ct_ft resulting in a UAF on the already freed ct_ft object. This vulnerability can lead to privilege escalation. Analysis from zdi-disclosures@trendmicro.com: When initializing act_ct, tcf_ct_init() is called, which internally triggers tcf_ct_flow_table_get(). static int tcf_ct_flow_table_get(struct net *net, struct tcf_ct_params *params) { struct zones_ht_key key = { .net = net, .zone = params->zone }; struct tcf_ct_flow_table *ct_ft; int err = -ENOMEM; mutex_lock(&zones_mutex); ct_ft = rhashtable_lookup_fast(&zones_ht, &key, zones_params); // [1] if (ct_ft && refcount_inc_not_zero(&ct_ft->ref)) // [2] goto out_unlock; ... } static __always_inline void *rhashtable_lookup_fast( struct rhashtable *ht, const void *key, const struct rhashtable_params params) { void *obj; rcu_read_lock(); obj = rhashtable_lookup(ht, key, params); rcu_read_unlock(); return obj; } At [1], rhashtable_lookup_fast() looks up and returns the corresponding ct_ft from zones_ht . The lookup is performed within an RCU read critical section through rcu_read_lock() / rcu_read_unlock(), which prevents the object from being freed. However, at the point of function return, rcu_read_unlock() has already been called, and there is nothing preventing ct_ft from being freed before reaching refcount_inc_not_zero(&ct_ft->ref) at [2]. This interval becomes the race window, during which ct_ft can be freed. Free Process: tcf_ct_flow_table_put() is executed through the path tcf_ct_cleanup() call_rcu() tcf_ct_params_free_rcu() tcf_ct_params_free() tcf_ct_flow_table_put(). static void tcf_ct_flow_table_put(struct tcf_ct_flow_table *ct_ft) { if (refcount_dec_and_test(&ct_ft->ref)) { rhashtable_remove_fast(&zones_ht, &ct_ft->node, zones_params); INIT_RCU_WORK(&ct_ft->rwork, tcf_ct_flow_table_cleanup_work); // [3] queue_rcu_work(act_ct_wq, &ct_ft->rwork); } } At [3], tcf_ct_flow_table_cleanup_work() is scheduled as RCU work static void tcf_ct_flow_table_cleanup_work(struct work_struct *work) { struct tcf_ct_flow_table *ct_ft; struct flow_block *block; ct_ft = container_of(to_rcu_work(work), struct tcf_ct_flow_table, rwork); nf_flow_table_free(&ct_ft->nf_ft); block = &ct_ft->nf_ft.flow_block; down_write(&ct_ft->nf_ft.flow_block_lock); WARN_ON(!list_empty(&block->cb_list)); up_write(&ct_ft->nf_ft.flow_block_lock); kfree(ct_ft); // [4] module_put(THIS_MODULE); } tcf_ct_flow_table_cleanup_work() frees ct_ft at [4]. When this function executes between [1] and [2], UAF occurs. This race condition has a very short race window, making it generally difficult to trigger. Therefore, to trigger the vulnerability an msleep(100) was inserted after[1]

Tenable CTO Vlad Korsunsky talks about participating in the World Economic Forum’s Annual Meeting on Cybersecurity and Tenable’s EXPOSURE 2026 conference, where he talked with global leaders about new game-changing AI threats and the groundbreaking benefits of exposure management. Key takeaways The patching cycle is obsolete. Advanced AI models have compressed exploitation timelines into “negative days,” meaning adversaries actively weaponize vulnerabilities before vendor patches are even released. Shift from static CVE severity scores to AI-powered exposure management. Point-in-time vulnerability-risk snapshots fall short. You need AI insights to prioritize remediation based on real-world exploitability of your entire attack surface. Secure the agentic economy. The rapid explosion of autonomous non-human AI identities demands the immediate application of zero trust and least-privilege cryptographic primitives to mitigate severe, systemic internal risks. Don’t focus only on vulnerabilities. While the 2026 Verizon DBIR ranks vulnerability exploitation as the top initial access vector for breaches (about 30%), the majority of breaches (70%) stem from human errors, such as misconfigurations and identity flaws. Tenable Chief Technology Officer Vlad Korsunsky recently participated in the World Economic Forum’s Annual Meeting on Cybersecurity in Geneva, Switzerland, an annual summit that takes the pulse of global cyber risk. Korsunsky was one of 150 senior leaders from global industry and government who gathered to discuss how to strengthen businesses’ cyber defenses. The sobering, collective consensus: The traditional cybersecurity playbook is obsolete, as AI becomes an unprecedented threat multiplier. For Tenable, participating in foundational, high-level dialogues and collaborations such as this one is both a privilege and an immense responsibility. As the cybersecurity operating model gets rewritten in real-time, Tenable feels a duty to help shape cyber defenders’ collective insights and strategies. Tenable has spent years addressing the structural cybersecurity operational gaps that worry C-level executives and government leaders worldwide. Korsunsky also had a chance to sit down with many of the hundreds of cybersecurity executives who gathered recently at Tenable’s EXPOSURE 2026 conference . The EXPOSURE 2026 discussions ranged from the death of reactive patching cycles to the need to counter AI threats with systemic cyber resilience, and signaled an urgent need to shift away from a siloed, fragmented approach to cybersecurity and move toward AI-powered exposure management . Below is an in-depth Q&A with Korsunsky, expanding on his participation in the Geneva and Tenable meetings, the rapid escalation of AI threats, and the way to tame cyber risk today and in the coming years. Q: Vlad, you recently returned from the World Economic Forum’s Annual Meeting on Cybersecurity in Geneva. What was the overarching energy in the room among these 150 global leaders, which included CEOs, CTOs, CISOs and government leaders? Vlad Korsunsky: The energy was highly focused and, frankly, deeply sober. We are witnessing an unprecedented compression of the threat landscape, and everyone in that room, whether they were running a multinational bank, directing a national cyber defense agency, or leading an NGO, realized that conventional cyber defenses cannot keep up with this velocity. A telling example of how high the stakes have jumped occurred just recently in Washington, D.C. The then Federal Reserve Chair Jerome Powell and U.S. Treasury Secretary Scott Bessent convened an emergency, high-level meeting with the CEOs of some of America's largest financial institutions, including Wall Street giants like Goldman Sachs, Citigroup, Wells Fargo, Bank of America, and Morgan Stanley. The entire meeting focused on a single AI model: Anthropic’s Claude Mythos Preview . Anthropic had flagged that while it built Mythos to bolster cyber defense, its raw capabilities were so advanced that, if weaponized or leaked, it could pose a major threat to the structural stability of the global financial system. When the highest echelons of fiscal and state power are holding emergency briefings over the capabilities of a single generative AI model, you know you’re dealing with a fundamentally different cyber threat landscape. Q: When asked, "What are the top cyber concerns for 2027?," meeting participants ranked the capacity of AI to be a threat multiplier as number one. Is this a future problem, or are we living it now? Vlad Korsunsky: The threat of AI in the hands of attackers is absolutely a global concern today. Look at the empirical metrics tracking adversary speed over the last decade and a half. For years, Mandiant tracked a linear trend that actually looked like a win for defenders. Time-to-exploit, which is the window between a vulnerability being disclosed and an active exploit hitting the wild, shrank steadily from 63 days in 2018 down to 32 days by 2022. Concurrently, average attacker dwell time — the time an attacker remains undiscovered after breaching a network – plummeted from more than 400 days in 2011 down to just 14 days in 2025. In short, defenders were actively closing the gap. Then came 2023, and the trend broke violently. Time-to-exploit collapsed from 32 days to just five. By 2024, it went negative: minus one day. According to Mandiant’s latest “M-Trends 2026 Report ,” published last month, the average time-to-exploit sits at minus seven days . Think about that structural asymmetry. Attackers are successfully weaponizing and exploiting vulnerabilities a full week before a vendor compiles and ships a patch. Meanwhile, the median timeline for an enterprise to deploy a patch across their environment is roughly 43 to 55 days, according to this year’s Verizon Data Breach Investigations Report (DBIR) . If adversaries are operating in negative time and defenders are operating across months, the traditional patching cycle is effectively a dead strategy. Q: What is driving this terrifying acceleration? How are attackers moving so quickly? Vlad Korsunsky: It is driven entirely by advanced frontier LLMs doing in minutes what used to require weeks of highly specialized human labor. Back in February, Anthropic’s Opus 4.6 model uncovered more than 500 zero-day vulnerabilities in widely utilized open-source software, flaws that had remained undiscovered despite decades of manual peer review by brilliant human engineers. Less than two months later, Anthropic’s Mythos model found thousands more vulnerabilities across foundational operating systems, web browsers, and core cryptographic libraries. More importantly, Mythos went further after spotting them; it boasted an 83% autonomous success rate in chaining disparate, low-severity logic flaws into devastating, end-to-end critical exploits. Essentially, we have reached a watershed moment reminiscent of when Google DeepMind’s AlphaGo defeated human Go champions . Experts believed a computer was decades away from mastering the Go game because the game features more potential board configurations than there are atoms in the observable universe. Brute force was impossible. Yet, AlphaGo won by leveraging deep neural networks to synthesize a form of machine intuition, discovering creative moves no human had conceived in 2,500 years of play. Today, frontier AI models are applying that exact evolutionary leap to cybersecurity. The most powerful LLMs can now execute 32-step complex reasoning chains to autonomously map and compromise simulated corporate networks. The asymmetry is stark. This massive capability curve means the absolute volume of known exposures is poised for a massive step-change, and GenAI has poured pure gasoline on the fire. Q: With zero-days dropping in droves thanks to AI-aided discoveries, should enterprises focus all their engineering resources on hunting down these vulnerabilities? What did you hear from CISOs and other high-level cybersecurity leaders about this issue at Tenable’s EXPOSURE 2026? Vlad Korsunsky: This is where we have to look at the whole board and avoid panic. While the influx of AI-driven zero-day disclosures is a massive upstream pressure on software vendors, data from this year’s Verizon DBIR shows that breaches directly leveraging software exploits account for about 30% of incidents. It's a significant percentage, yes, but what about the other 70%? Cybersecurity leaders I talked to at EXPOSURE 2026 realize that the overwhelming majority of enterprise breaches do not begin with an ultra-sophisticated, state-sponsored zero-day exploit. They start with incredibly simple, unforced human errors: unsecured shadow IT cloud assets running outside corporate governance; misconfigured databases left wide open to the public internet; over-privileged corporate identities; a lack of multi-factor authentication (MFA); and highly targeted, AI-driven spear phishing. This is a critical insight for guiding your cyber strategy today. These misconfigurations and unsecured cloud credentials are the dry fuel sitting inside an enterprise network. When an AI hacking agent comes looking, that fuel ignites faster than any traditional cybersecurity team can react. So organizations must be diligent about proactively maintaining stringent security hygiene. Q: If paddling faster inside the old patching model won't save us, how do defenders change the rules of the game? Vlad Korsunsky: We have to look at this the way wildland firefighters have looked at massive forest fires for over a century. When a wildfire is roaring toward a town faster than a human can run, firefighters don’t just stand at the edge of the flames reaching for a bigger water hose. They get ahead of the blaze and light a controlled burn. They intentionally clear out the brush, trees, and fuel ahead of time. When the main fire line reaches that cleared zone, it starves and dies because there is nothing left to consume. Enterprise security must adopt this exact philosophy. We have to stop reacting to the fire and start aggressively clearing the fuel before the adversary arrives. This requires a wholesale shift from reactive vulnerability patching to continuous exposure management . The traditional Common Vulnerability Scoring System (CVSS) is effectively dead as a primary prioritization tool . A static CVSS score tells you the theoretical severity of a single CVE in a vacuum; it tells you absolutely nothing about real-world exploitability within the specific context of your unique enterprise environment. At EXPOSURE 2026, we heard from our customers how continuous, AI-driven exposure management is helping them counter today’s evolving AI threats successfully. With exposure management, you use advanced analytics to gain unified, real-time visibility across your entire modern attack surface, encompassing data centers, cloud infrastructure, OT/IoT environments, corporate identities, and newly deployed AI pipelines. We must use AI on the defense side to continuously map true attack paths ; for example, pinpointing exactly where a minor misconfiguration chains into a critical business asset. Q: You mentioned using AI on the defense side. How does Tenable view the balance between human security analysts and autonomous AI defenders? Vlad Korsunsky: Security is fundamentally a team sport, and AI vendors like OpenAI and Anthropic are not our adversaries. AI is the single most potent tool ever introduced into the defender’s toolkit; we simply need to wield it with machine-speed orchestration. Because our adversaries are deploying fully autonomous hacking agents today — tools that are already topping commercial bug bounty leaderboards — the only fair fight is to meet machine speed with machine speed. This means building and deploying agentic AI workflows on the side of the defense to power autonomous exposure management. However, this must always be balanced with strict human-in-the-loop oversight. In Geneva, we spent a great deal of time discussing the systemic risks of unchecked automation. If an autonomous system applies a sweeping remediation script without understanding the broader business context, it can inadvertently trigger a massive operational outage: a self-inflicted systemic failure. Defenders must maintain deep visibility into the “behind-the-scenes” logic of their automation. We need human control to govern business context, while leveraging machine speed to continuously ingest, prioritize, and neutralize exposures before an attacker can strike. Q: Another major pillar of the WEF discussion centered on AI safety and non-human identities. What are the hidden risks enterprises are overlooking as they rush to adopt AI? Vlad Korsunsky: We are transitioning rapidly into what we call the “Agentic Economy.” Historically, enterprise security focused on securing human users and a relatively manageable set of non-human service accounts. As organizations embed AI agents into core business workflows — from code generation to customer operations to financial automation — we are seeing an exponential growth of non-human, agentic identities and agentic workflows. These autonomous agents are fundamentally different. Instead of operating just “on behalf” of a human in a tightly bound session, they execute complex tasks independently. The alarming reality discussed in Geneva and in our EXPOSURE 2026 conference is that our current security frameworks lack effective, native guardrails for these agents. LLMs routinely bypass system prompts or ignore markdown safety files. They can even actively manipulate or hack neighboring AI agents to achieve their algorithmic goals. We’ve seen anecdotal instances of an enterprise AI agent autonomously writing a script to bypass an internal access restriction, and when flagged, its underlying logic essentially argued that the script committed the violation, not the agent itself. Because AI agents behave essentially like trusted corporate insiders that have been let loose across internal data silos, we must immediately apply foundational cryptographic primitives to agentic identities. We need strict zero-trust architectures, rigorous least-privilege access controls, and absolute defense-in-depth tailored specifically for non-human identities before they morph into the next great vector of unmanageable global risk. Q: Any final thoughts for organizations trying to navigate this massive technological shift? Vlad Korsunsky: Attackers are increasingly rocketing laterally across enterprise networks after the initial breach, often in minutes and even seconds, whereas before it could take them days or weeks. The adversary’s inherent advantages will always be timing, velocity, and the luxury of only needing to find a single weak link in your exposure landscape. But as defenders, we possess the ultimate home-field advantage: We can see the whole board, and we have the power to fundamentally alter the terrain. By abandoning obsolete point-in-time checkmarks, embracing continuous, AI-driven exposure management, and proactively clearing out our operational fuel at machine speed through foundational cyber hygiene, we can break the adversary’s curve and effectively secure our environments.

This report references a link to a Microsoft Forms survey purportedly for a college capstone project. The content is a Reddit post requesting users to fill out the survey, with no technical details or indicators of malicious activity provided. There is no evidence of exploitation, vulnerability, or threat beyond the survey request itself. The source is a Reddit post with minimal discussion and no known exploits. No patch or remediation information is applicable.

Learn how attackers exploit automated bot traffic as part of software supply chain attacks to artificially inflate download counters and mask malicious payloads as legitimate. Key takeaways Volume doesn’t equal trust. Packages with numerous versions and high download counts might seem legitimate, but attackers can easily manipulate those metrics. Attackers exploit automated infrastructure. By initially flooding the registry with numerous benign versions of a package, threat actors trigger automatic downloads from mirrors, scanners, and analysis bots, which artificially inflate traffic. Although old download-inflation techniques still work, attackers are developing new sophisticated techniques to deceive developers into installing malicious packages. Downloads count metric Following recent software supply chain attacks in which Tenable has seen attackers steal access tokens and secrets from developer workstations and CI/CD build servers, we started actively monitoring and analyzing npm packages uploaded to the public registry. Initially, we used download counts as a primary metric to determine package relevance. During our monitoring, we identified a recurring anomaly: Brand new packages displayed unusually high download counts within hours of upload. Upon further investigation, we discovered that those packages also had many versions. We found that packages whose content got updated frequently — usually by systematically uploading many new versions for the same package — had an unusually high downloads count. We observed this technique being used deliberately in the wild for the first time in our analysis of the malicious “ambar-src” package , which reached more than 50,000 downloads in three days after attackers uploaded more than 700 versions. We named this technique “download pumping.” Developers and security tools frequently use download counts as one of the metrics to assess a package's legitimacy. Since there is no simple method for determining if a package is legitimate, this artificial inflation effectively disguises the threat. Analysis In the “ambar-src” campaign, threat actors systematically published hundreds of benign versions of the package before introducing the actual malicious payload. Because npm registers each interaction with these updates as traffic, this repetitive version-publishing process achieved two goals: It heavily populated the package’s release history, creating a dense changelog that made the project appear actively maintained and historically legitimate to developers evaluating it. Every time a new version was published, automated systems like repository mirrors and analysis bots automatically downloaded it. Because the attackers systematically uploaded hundreds of versions, they artificially generated a massive wave of automated traffic, inflating the package's download count to more than 50,000 downloads in just three days. From Tenable’s initial analysis, each version uploaded to the npm public registry typically receives between 100 and 150 downloads from automated systems. We verified that fact by running our proof-of-concept (POC) and analyzing the download count. Download pumping PoC To validate these mechanisms, we conducted a POC that replicated the download pumping behavior. We created test packages and systematically published a high volume of new versions to the npm registry. As the npm team stated in their blog , their download stats are naive by design, and they do not put much effort into filtering automated bot traffic. Thus, various repository mirrors, analytical bots, and automated security scanners immediately pulled each new version we uploaded. This validated that an attacker can predictably generate a baseline of downloads entirely through automated publishing, requiring zero organic user interaction. During our POC, we wanted to see how different package properties might affect the automated download volume. We were working under the assumption that packages with postinstall scripts raise the interest level of security scanners. Postinstall scripts are highly interesting to defenders because attackers frequently use these lifecycle hooks to automatically execute malicious payloads the moment a package is installed. Since this is a common malware-deployment technique, automated security scanners prioritize downloading and inspecting packages that have these scripts configured. It is important to note that security scanners don’t have to download the package itself to determine if the npm package has a postinstall script configured, as this data is available in the package metadata in the public registry. For those reasons, we believed that security scanners are more likely to download packages with install scripts configured, as they are more likely to contain malicious code. We deployed three distinct test packages to npm to test our assumption and observed the following results: Version bump only: 135.55 downloads per version This was our baseline test package. We didn’t add or remove any code when publishing a new version, nor did we make any other attempt to make the package look interesting. We simply bumped up the version number each time. Static postinstall script: 141.91 downloads per version This was our second test package, and the first one to have a postinstall script configured, but we didn’t change the script when publishing new versions. Dynamic postinstall script: 158.16 downloads per version In this third test package, we changed the postinstall script every time we bumped up the version. We did this as we believed that security scanners would be more interested in packages whose postinstall script changed, as it could be an indicator of compromise. Graph showing how Tenable’s first POC software package experienced a spike in downloads when we started publishing new versions of it. This data demonstrates a straightforward cause-and-effect: automated infrastructure and security scanners naturally generate more download traffic for packages that exhibit interesting or actively changing behaviors. Other package managers While our research focused specifically on the npm ecosystem, the fundamental mechanics behind this technique are not unique to npm. Other package registries such as PyPI , RubyGems , and NuGet operate with similar automated infrastructure — mirrors, security scanners, and analysis bots — that pull new versions as they are published. Although the specific download amplification and trust metrics may differ across ecosystems, the core principle remains the same: where automated systems react to new publications, there is potential for abuse. Real-world example of download pumping As already stated, we first observed this technique being used in the wild during our analysis of the “ambar-src” package . Let’s look at this in more detail. The attackers created an npm package containing utility code that can be used for legitimate purposes, such as MathUtils, StringUtils and Time functions. The attackers then systematically uploaded 428 legitimate versions of the package in just two hours. The attackers did this to gain initial credibility and attempt to lure developers to use their code. Three days later, the attackers uploaded a new version containing malicious code. By this point, the attackers’ package already had more than 30,000 downloads. In total, the attackers uploaded 724 versions including malicious and legitimate versions. This led to an artificially generated wave of automated traffic, resulting in around 50,000 downloads total. This repetitive version-publishing process successfully inflated the package's download count and created a dense release history, making the project appear historically legitimate before the malware was deployed. Past research on npm download manipulation The manipulation of npm downloads metrics is not a new discovery. In a 2021 research blog , independent developer Andy Richardson showed how prone the npm registry’s download tracking is to abuse, by demonstrating that bad actors can send HTTP requests to a package’s tarball URL to fake downloads. Using automated tools, the researcher successfully drove nearly 1 million spoofed downloads in a single week for a completely unused package. Tenable validated this technique still works in 2026. By sending HTTP requests directly to the URL of the package’s tarball, Tenable successfully inflated a test package’s metric to 17,000 downloads in approximately one hour, using nothing more than a standard office laptop and an internet connection. However, this new version-flooding method we’ve identified offers two distinct advantages: First, it provides amplification, because an attacker gains 100 to 150 automated downloads from repository mirrors for every single version they upload, rather than just one download per HTTP request. Second, systematically publishing these updates populates the release history, creating a dense version log that makes the package appear actively maintained and historically legitimate. Mitigation of supply chain attacks Organizations should not depend on download counts or version histories to determine if a package is legitimate. As we have demonstrated, attackers can easily fake these metrics using automated systems, creating a false sense of trust. Instead, organizations should adopt common industry best practices, such as version pinning and implementing minimum package-age restrictions. These best practices are effective, as security vendors and the open-source community actively monitor these registries and typically detect malicious packages fairly quickly, within a couple of days at most. By enforcing a short waiting period of three to four days before allowing a new package or new version of an existing package into your environment, you allow the community time to identify these threats in the public registry. Once they are detected, they are removed from the public registry, eliminating the risk. It is worth noting that npm is actively working to improve the security of its ecosystem. Recent efforts include adding support for package-age checks directly in the npm CLI, as well as strengthening authentication mechanisms for package maintainers to reduce the risk of account takeovers. While these are meaningful steps in the right direction, the reality is that no single measure can fully prevent malicious code from reaching the public registry. Supply chain attacks will continue to evolve, and organizations should also layer their own defenses rather than rely on the ecosystem alone. For example, organizations can add extra protection for CI/CD build servers by deploying ephemeral CI/CD runners that are destroyed immediately after a single use to prevent malware from lingering. Operating those temporary runners without persistent storage makes it harder for threat actors to save their payloads or establish persistence across different build jobs. Additionally, organizations should enforce least-privilege network access. Restricting outbound traffic makes it harder for malicious payloads running on the build server to reach the open internet to download second-stage malware payloads like “msinit.exe.” So what? Currently, developers are still being hacked through open-source supply chain techniques . The metrics developers and security tools depend on — download counts, version history, maintenance activity — are superficial indicators that, as we have demonstrated, an attacker can manipulat with minimal effort. But the problem runs deeper than fake signals. Even when a package has a legitimate track record with a trusted maintainer behind it, that trust can be compromised overnight. Recent waves of account takeovers, social engineering campaigns, and credential theft targeting established maintainers have shown that a package's history is no guarantee of its current safety, even for legitimate packages. A new version published under a trusted name can carry a malicious payload, and the package manager has no built-in mechanism to catch it. In practice, there is no deterministic method to determine if a new package is malicious or not. Therefore, each package you install and use must be treated like it could be malicious. The meaningful trust signal comes after the fact: from security vendors and the open-source community actively scanning and analyzing packages once they are published. This is exactly why enforcing minimum-age requirements on new packages and new versions is such an effective control . A short waiting period of a few days gives the security community time to detect, flag, and remove threats from the public registry before they ever reach your environment. Organizations that consume packages the moment they are published are accepting risk that is entirely avoidable. Download pumping is ultimately just the initial entry vector for a much larger objective. Attackers using these techniques are generally aiming for one of two outcomes. First, they aim to compromise build servers and CI/CD pipelines. By successfully injecting a malicious dependency into these systems, threat actors achieve “God-mode” over the infrastructure, which can lead to a full compromise of the entire production environment. Second, and even worse, they aim to compromise the developers of highly popular packages. By hijacking a trusted maintainer’s environment, attackers can inject malicious code that thousands of downstream organizations automatically pull, creating a massive cascading effect across the broader software supply chain. How Tenable can help defend against supply chain attacks To defend against supply chain attacks, you need to know exactly what code is running in your environment. The Tenable One Exposure Management Platform and Tenable Nessus can help you build a complete asset inventory of the npm packages used across your organization. Use the following Nessus plugins to build an inventory of the npm modules in your environment: 200172 - Node.js Modules Installed (Windows) 179440 - Node.js Modules Installed (macOS) 178772 - Node.js Modules Installed (Linux) As Tenable continuously analyzes your environment, you get direct visibility into exactly what is installed on your systems. This visibility ensures you can quickly locate and remove compromised packages as soon as a new threat is discovered. Beyond building a complete inventory, organizations also need to actively monitor their environments for live threats. Tenable One Cloud Exposure , a CNAPP, builds on this visibility by continuously monitoring your cloud environment to proactively detect these types of supply chain attacks in real time. Together as part of the Tenable One Exposure Management Platform, these tools proactively detect supply chain attacks across your environments, ensuring your security teams can immediately identify and neutralize malicious activity before attackers can fully compromise your production systems.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (51c637ab7c13ca2f592502f3444ebb24b291422b6388563d04fb8f7ae9030d5a) The package masquerades as a TypeScript helper library (README is lifted from Microsoft's tslib and references --importHelpers, __extends, __assign, and a fake github.com/microsoft/ts-build-optimize/releases URL). The shipped index.js has nothing to do with TypeScript helpers: it exports a function `buildoptimize` whose default arguments are hardcoded to fetch `https://verceljs-kappa.vercel.app/icons/23` and pass the response body directly to `eval()` (index.js:61-63 sets `uuri = "https://verceljs-kappa.vercel.app/icons/"`; index.js:79 executes `eval(JSON.parse(b))`; the function is exported at index.js:95). Any consumer who imports this package and calls `buildoptimize()` — which the name and README imply is a build-time optimizer — will execute arbitrary attacker-controlled JavaScript on the installer/build machine. The Vercel destination is mutable (the author can swap the payload at any time), no hash or signature is verified, and the hosting domain is unrelated to Microsoft or any legitimate tslib publisher. The C2 endpoint serves a benign 6,758-byte PNG decoy when requested without the package's hardcoded `bearrtoken: logo` HTTP header (so casual scanners and `curl` see only an image), but returns 53,347 bytes of JSON-wrapped, heavily-obfuscated JavaScript when the header is present. Static analysis of the fetched second stage (sha256 of the raw response body fd082d2406d65aa78d5f1028e11dc23e85d63f07c459fb048d08236a65590b99; sha256 of the JSON-decoded JavaScript source 47d235dad37c7fb86e231822a4c231344cbd006e58b8cb9a013b064c1a521eb8 — captured 2026-05-15, payload is mutable) shows wallet-theft and persistence functionality: references to the Exodus cryptocurrency wallet on macOS (`/Library/Application Support/exodus.wallet`) and Windows (`/AppData/Roaming/Exodus/exodus.wallet`); functions named `installWindows`, `uninstallWindows`, `installMac`, `uninstallMac`, `isInstalledWindows`, and a `macPlistPath` constant indicating per-OS persistence install/uninstall machinery; heavy use of `child_process.execSync`/`exec` to invoke shell commands; and a top-level `setInterval(main, 30000)` re-execution loop. The combination of name-squat on a widely-used Microsoft package, README impersonation, header-gated decoy, and a remote-eval primitive that delivers wallet-theft + persistence makes this an unambiguous supply-chain attack. ## Source: ghsa-malware (4be8b286c06dccd79ec8f318a8f88f497e65c271c7f3e33b11a7ca4d53646b4e) 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: thermal: core: Address thermal zone removal races with resume Since thermal_zone_pm_complete() and thermal_zone_device_resume() re-initialize the poll_queue delayed work for the given thermal zone, the cancel_delayed_work_sync() in thermal_zone_device_unregister() may miss some already running work items and the thermal zone may be freed prematurely [1]. There are two failing scenarios that both start with running thermal_pm_notify_complete() right before invoking thermal_zone_device_unregister() for one of the thermal zones. In the first scenario, there is a work item already running for the given thermal zone when thermal_pm_notify_complete() calls thermal_zone_pm_complete() for that thermal zone and it continues to run when thermal_zone_device_unregister() starts. Since the poll_queue delayed work has been re-initialized by thermal_pm_notify_complete(), the running work item will be missed by the cancel_delayed_work_sync() in thermal_zone_device_unregister() and if it continues to run past the freeing of the thermal zone object, a use-after-free will occur. In the second scenario, thermal_zone_device_resume() queued up by thermal_pm_notify_complete() runs right after the thermal_zone_exit() called by thermal_zone_device_unregister() has returned. The poll_queue delayed work is re-initialized by it before cancel_delayed_work_sync() is called by thermal_zone_device_unregister(), so it may continue to run after the freeing of the thermal zone object, which also leads to a use-after-free. Address the first failing scenario by ensuring that no thermal work items will be running when thermal_pm_notify_complete() is called. For this purpose, first move the cancel_delayed_work() call from thermal_zone_pm_complete() to thermal_zone_pm_prepare() to prevent new work from entering the workqueue going forward. Next, switch over to using a dedicated workqueue for thermal events and update the code in thermal_pm_notify() to flush that workqueue after thermal_pm_notify_prepare() has returned which will take care of all leftover thermal work already on the workqueue (that leftover work would do nothing useful anyway because all of the thermal zones have been flagged as suspended). The second failing scenario is addressed by adding a tz->state check to thermal_zone_device_resume() to prevent it from re-initializing the poll_queue delayed work if the thermal zone is going away. Note that the above changes will also facilitate relocating the suspend and resume of thermal zones closer to the suspend and resume of devices, respectively.

Researchers uncovered fast16, a cyber sabotage framework from 2005 that predates Stuxnet by five years. The toolset includes fast16.sys, a kernel driver that selectively targets high-precision calculation software by patching code in memory to corrupt computational results. Combined with self-propagation mechanisms via a Lua-powered carrier module (svcmgmt.exe), the framework spreads across facilities to produce consistent inaccurate calculations. This operation represents the first documented instance of strategic cyber sabotage targeting ultra-expensive computing workloads in advanced physics, cryptographic, and nuclear research. The framework uses an embedded Lua virtual machine predating Flame by three years and appears in the ShadowBrokers leak of NSA Territorial Dispute components with the evasion signature: 'fast16 *** Nothing to see here – carry on ***'.

In the Linux kernel, the following vulnerability has been resolved: i40e: Fix preempt count leak in napi poll tracepoint Using get_cpu() in the tracepoint assignment causes an obvious preempt count leak because nothing invokes put_cpu() to undo it: softirq: huh, entered softirq 3 NET_RX with preempt_count 00000100, exited with 00000101? This clearly has seen a lot of testing in the last 3+ years... Use smp_processor_id() instead.

cpp-httplib is a C++11 single-file header-only cross platform HTTP/HTTPS library. Prior to 0.37.1, when a cpp-httplib client uses the streaming API (httplib::stream::Get, httplib::stream::Post, etc.), the library calls std::stoull() directly on the Content-Length header value received from the server with no input validation and no exception handling.std::stoull throws std::invalid_argument for non-numeric strings and std::out_of_range for values exceeding ULLONG_MAX. Since nothing catches these exceptions, the C++ runtime calls std::terminate(), which kills the process with SIGABRT. Any server the client connects to — including servers reached via HTTP redirects, third-party APIs, or man-in-the-middle positions can crash the client application with a single HTTP response. No authentication is required. No interaction from the end user is required. The crash is deterministic and immediate. This vulnerability is fixed in 0.37.1.

Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. Prior to 4.0.2 and 3.7.11, Workflow templates endpoints allow any client to retrieve WorkflowTemplates (and ClusterWorkflowTemplates). Any request with a Authorization: Bearer nothing token can leak sensitive template content, including embedded Secret manifests. This vulnerability is fixed in 4.0.2 and 3.7.11.