Search: SHA-256

A malicious file identified by the SHA-256 hash ce7568afc34c67e286c731c882d03a9b2a8401b04fbd4613f5bcb98f4b09a277 was observed by OffSeq Mirage honeypot sensors six times between July 25 and July 28, 2026. The activity involved the MITRE ATT&CK technique T1105 (Ingress Tool Transfer), indicating the file was used to stage or deliver a malicious payload such as a dropper, web shell, miner, or post-exploitation tool. The file originated from attacker infrastructure located in MU. This indicator can be used to detect or block the associated malicious payload in affected environments.

A malicious file identified by the SHA-256 hash b26f0922377fe34dcfb3df39c497b5cf4bd491aa2678196d976586adef85ac64 was observed by OffSeq Mirage honeypot sensors six times between July 25 and July 28, 2026. The file is associated with attacker activity involving the MITRE ATT&CK technique T1105 (Ingress Tool Transfer). This hash fingerprints a specific malicious payload that could be a dropper, web shell, miner, or post-exploitation tool. The threat was observed originating from attacker infrastructure located in MU. No known exploits in the wild or specific affected software versions are identified. The indicator is intended for matching against files in environments and security feeds to detect potential compromise.

A malicious file identified by the SHA-256 hash 9ab6e598d685e617ad0194d390257dc2061124a5b44ba003b8caa7d6c40516d6 was observed by OffSeq Mirage honeypot sensors on July 25, 2026. The file was detected twice in attacker activity originating from infrastructure in Mauritius (MU). The observed attack technique is T1105 (Ingress Tool Transfer), indicating the file was used to stage or deliver a malicious payload such as a dropper, web shell, miner, or post-exploitation tool. There are no known exploits in the wild associated with this file hash, and no affected software versions are specified.

### Summary Budibase's central outbound-fetch guard (`fetchWithBlacklist`) prevents SSRF/DNS-rebinding by resolving the target hostname, checking every resolved IP against the blacklist, and **pinning** the connection to the validated IP. The pin is implemented as a Node `http(s).Agent` (`makePinnedAgent`). The fix for CVE-2026-54353 relies on this pin to stop DNS rebinding. The REST datasource integration (`@budibase/server`) calls `fetchWithBlacklist` but performs the actual request with **undici**'s `fetch`. undici does not support the Node `agent` option — it is silently ignored — and instead uses its own `dispatcher`, which re-resolves the hostname's DNS at connection time. As a result, **the validated/pinned IP is never used on the REST datasource path**, and the DNS-rebinding protection that CVE-2026-54353 added is silently defeated for the single most-used outbound path in Budibase. An authenticated user who can configure/run a REST datasource (e.g. a builder/tenant) can use a rebinding hostname (public IP during validation, internal IP at connect) to make the server issue arbitrary, full-response HTTP requests to internal-only services — cloud metadata (IAM credential theft), the internal CouchDB/Redis/MinIO, and other internal endpoints — reading and, because REST datasources allow arbitrary method/body, writing or destroying internal data. ### Details **The guard pins the validated IP via a Node agent** — `packages/backend-core/src/utils/outboundFetch.ts`: - `resolveSafePinnedIp(url)` resolves the hostname and checks every address against `isBlacklisted`, returning a single `pinnedIp` (lines ~39–53). - `makePinnedAgent(url, ip)` builds a **Node** `http.Agent`/`https.Agent` whose `lookup` always returns `pinnedIp`, so a node-fetch connection can only reach the validated IP (lines ~55–68). - `fetchWithBlacklist` passes that agent into the request: `fetchFn(nextUrl, { ...nextRequest, agent: makePinnedAgent(nextUrl, pinnedIp) })` (lines ~186–192). Each redirect hop is re-validated and re-pinned in the loop. **The REST integration overrides the transport with undici, which ignores `agent`** — `packages/server/src/integrations/rest.ts`: - `fetch` is imported from **`undici`** (top-of-file import block, ~line 30). - The request is made by overriding `fetchFn` (lines ~767–793): ```ts const setDispatcher = (requestInput, requestUrl) => ({ ...requestInput, dispatcher: getDispatcher({ rejectUnauthorized, url: requestUrl }), }) ... response = await coreUtils.fetchWithBlacklist(url, input, { fetchFn: async (requestUrl, requestInput) => fetch(requestUrl, setDispatcher(requestInput, requestUrl)), // undici.fetch }) ``` The options object reaching `undici.fetch` is `{ ...nextRequest, agent: <pinned Node Agent>, dispatcher: <getDispatcher result> }`. **undici uses `dispatcher` and ignores `agent`.** **The dispatcher does no IP pinning** — `packages/backend-core/src/utils/fetch.ts`: - `getDispatcher` → `createDispatcher` → (no proxy env) → `createDirectAgent` = `new Agent({ connect: { rejectUnauthorized } })` (lines ~109–114, ~161–172, ~183). This is a plain undici `Agent` with **no `connect.lookup` / no pin**, so undici resolves the hostname's DNS itself at connect time. **Net effect (TOCTOU / DNS rebinding):** `fetchWithBlacklist` validates the hostname → safe public IP and builds a pinned Node agent; the REST path then connects via undici, which re-resolves the same hostname independently. With a rebinding domain (TTL 0: public IP during validation, `127.0.0.1` / `169.254.169.254` / internal IP at connect), the request lands on an internal service — exactly the gap CVE-2026-54353's pin was meant to close. **Scope of impact / why it's REST-specific:** `rest.ts` is the only caller that overrides `fetchFn` with undici. All other outbound sinks (automation `outgoingWebhook`/`n8n`/`make`/`zapier`/`discord`/`slack`, and AI-extract's `processUrlFile`) use the default node-fetch-based `fetchWithBlacklist`, which **does** honor the pinned agent and is **not** affected. REST datasource queries are the most common outbound path, and the response body is returned to the caller (full-response SSRF, not blind). ### PoC The PoC drives the **real, unmodified** guard code (`outboundFetch.ts` + `fetch.ts`, copied verbatim — sha256 verified) and reproduces the exact `rest.ts` call pattern. Only the `../blacklist` module is stubbed to model the rebinding **input** (validation observes a safe public IP). Requires Node 18+. ```bash # prerequisite: a Budibase checkout; set BB to its path export BB=/path/to/budibase mkdir ssrf-poc && cd ssrf-poc SRC="$BB/packages/backend-core/src" # 1) Copy the REAL guard code, verbatim (sha proves no edits) mkdir -p real/utils real/blacklist cp "$SRC/utils/outboundFetch.ts" real/utils/ cp "$SRC/utils/fetch.ts" real/utils/ # 2) Scenario stub = the rebinding INPUT: validation sees a safe, non-blacklisted public IP cat > real/blacklist/index.ts <<

A malicious file identified by the SHA-256 hash 01dc4719944a22b0d4fc55112ed7d7366ea82773ffa178bedf472b3d66d8b3b9 was observed by OffSeq Mirage honeypot sensors four times between July 23 and July 28, 2026. The activity involved the MITRE ATT&CK technique T1105 (Ingress Tool Transfer), indicating the transfer of a malicious payload such as a dropper, web shell, miner, or post-exploitation tool. The file was seen originating from attacker infrastructure located in MU. There is no information on active exploitation in the wild or known threat actors associated with this hash. No affected software versions or patches are applicable as this is an indicator of compromise rather than a software vulnerability.

A malicious file identified by the SHA-256 hash 9600dc90de0e5b779cdb592b7bb0b0574c48e1c9f3843c93359897122c441034 was observed by OffSeq Mirage honeypot sensors 10 times between July 23 and July 28, 2026. The file is associated with attacker activity involving the MITRE ATT&CK technique T1105 (Ingress Tool Transfer). This hash fingerprints a specific malicious payload that could be a dropper, web shell, miner, or post-exploitation tool. The threat was observed originating from attacker infrastructure located in MU. There is no indication of known exploits in the wild or specific affected software versions. No patch or remediation information is provided.

A malicious file identified by the SHA-256 hash cda62e4f1121da4c98747dde8e4f79acb4a95fb8e8ce8412023e9b04c985bd2b was observed by OffSeq Mirage honeypot sensors five times between July 23 and July 28, 2026. The file is associated with attacker activity involving the MITRE ATT&CK technique T1105 (Ingress Tool Transfer). This hash fingerprints a specific malicious payload that could be a dropper, web shell, miner, or post-exploitation tool. The threat was seen originating from attacker infrastructure located in MU. No known exploits in the wild or vendor patches are indicated. Organizations are advised to match this hash against their environments and security feeds to detect potential compromise.

A malicious file identified by the SHA-256 hash a64aadbc9c68fad12433ca75b2ded3c70db9a73ada83c7abf4882b04cd91f500 was observed by OffSeq Mirage honeypot sensors six times between July 23 and July 26, 2026. The activity involved the ATT&CK technique T1105 (Ingress Tool Transfer), indicating the file was transferred from attacker infrastructure. The file is associated with malicious payloads such as droppers, web shells, miners, or post-exploitation tools. No specific affected software versions or patches are identified. No known exploits or threat actors are linked to this indicator at this time.

A malicious file identified by the SHA-256 hash 89e89ac00b0c3adcf25435c19dfc828d87e5bb311c9a858f56e8463b14b3e254 was observed by OffSeq Mirage honeypot sensors on July 23, 2026. This file was detected twice in attacker activity involving the T1105 technique (Ingress Tool Transfer), indicating it was used to stage or deliver a malicious payload such as a dropper, web shell, miner, or post-exploitation tool. The attacker infrastructure was located in MU. No specific affected software versions or exploits in the wild are reported. The file hash serves as an indicator of compromise for detection and response efforts.

A malicious file identified by the SHA-256 hash 63be5f38b520b3143732962a5f8fec1f9abd1f483dbc741ed324e58f955dd35e was observed by OffSeq Mirage honeypot sensors on July 23, 2026. The file was detected twice in attacker activity involving the T1105 technique (Ingress Tool Transfer) from attacker infrastructure located in Germany. This hash corresponds to a specific malicious payload such as a dropper, web shell, miner, or post-exploitation tool that was staged or delivered during the attack. No known exploits in the wild or affected software versions are identified. The indicator is intended for matching against files in environments and security tools to detect potential compromise.

A malicious file identified by the SHA-256 hash e2bc7981064d3c9ed898a0f62d659fdc2fc9646dee47a9ca92b9b28b96c27a3b was observed twice on July 23, 2026, by OffSeq Mirage honeypot sensors. The file is associated with attacker activity involving the MITRE ATT&CK technique T1105 (Ingress Tool Transfer) and was seen originating from attacker infrastructure in Germany. This hash fingerprints a specific malicious payload that could be a dropper, web shell, miner, or post-exploitation tool. No known exploits in the wild or affected software versions are identified. The threat is categorized as an indicator of compromise (IOC) for detection and response purposes.

A malicious file identified by the SHA-256 hash b3232d2cd03b051c59aef952ecfea3358c172351a27a989df31720395c3cbb4a was observed by OffSeq Mirage honeypot sensors on July 23, 2026. The file was detected twice during attacker activity originating from infrastructure in Germany. The observed technique corresponds to T1105 (Ingress Tool Transfer), indicating the file is likely a payload such as a dropper, web shell, miner, or post-exploitation tool used in attacks. This indicator can be used to detect the presence of this malicious payload in environments by matching the hash against files in endpoint detection and response (EDR), antivirus (AV), and threat intelligence feeds.

A malicious file identified by the SHA-256 hash 3edfb02c0e6b2fe4894425cd0d4d2507f7cb11e0958674422729366a0d885c7e was observed by OffSeq Mirage honeypot sensors on July 23, 2026. The file was detected twice in attacker activity involving the T1105 technique (Ingress Tool Transfer). The malicious payload could be a dropper, web shell, miner, or post-exploitation tool. The attacker infrastructure was located in Germany. This indicator can be used to detect and block this specific malicious file in security environments.

A malicious file identified by the SHA-256 hash efa731b59f9e2f277336072fe5c72b488793c842e2efeedf5cb571a0eeb224e2 was observed by OffSeq Mirage honeypot sensors on July 23, 2026. The file was detected twice during attacker activity involving the T1105 technique (Ingress Tool Transfer). This hash corresponds to a specific malicious payload such as a dropper, web shell, miner, or post-exploitation tool. The attacker infrastructure was located in Germany (DE).

A malicious file identified by the SHA-256 hash dc2416a0d219b6a417f4fb1dfdcabd4e1326a13f772781be2769921291eeba7d was observed by OffSeq Mirage honeypot sensors on 2026-07-22. This file was seen 10 times in attacker activity originating from infrastructure in Great Britain. The activity involved the MITRE ATT&CK technique T1105 (Ingress Tool Transfer), indicating the file is likely a payload used for malicious purposes such as a dropper, web shell, miner, or post-exploitation tool. No specific affected software versions or patches are associated with this indicator. No known exploits in the wild or threat actors are linked to this hash at this time.

A malicious file identified by the SHA-256 hash d079a02683cde96446dae0624843f3a0ce1641a26a75083b9aef4cc8b892343a was observed 45 times in attacker activity between July 22 and July 30, 2026. The file is associated with the ATT&CK technique T1105 (Ingress Tool Transfer) and was seen originating from attacker infrastructure in multiple countries including Argentina, Brazil, China, India, Jordan, Pakistan, Russia, and Sweden. This hash fingerprints a specific malicious payload which could be a dropper, web shell, miner, or post-exploitation tool. There is no information about known exploits in the wild or affected software versions. The indicator is intended for matching against files in environments and security tools to detect potential compromise.

### Summary A personal access token (PAT) or OAuth2 token that does **not** carry the `repository` scope or that is **public-only** is correctly rejected (HTTP 403) by the recently hardened web content routes (archive download, raw/media file download, and repository RSS/Atom feeds). However, the repository home page route `GET /{owner}/{repo}` (handler `repo.Home`) serves the **private** repository's rendered README, root file/directory tree, description, language statistics, license, and latest-release information to that same token. This is a token-scope enforcement bypass and private-repository content disclosure. It is the same source→sink pattern already fixed for neighbouring routes in: - **GHSA-cr4g-f395-h25h** (CVE-2026-20706) token scope bypass on web archive download - **GHSA-3pww-vcvm-3gmj** (CVE-2026-27761) token scope bypass on repository RSS/Atom feeds `repo.Home` is the remaining token-auth-enabled content route that was not given the guard. ### Details / Root cause Web routes accept token authentication only when explicitly opted in with `webAuth.AllowBasic` / `webAuth.AllowOAuth2`. The repository home route carries `AllowBasic` (added so that `go get` can resolve private modules): ```go // routers/web/web.go:1256 m.Get("/{username}/{reponame}", optSignIn, webAuth.AllowBasic, context.RepoAssignment, context.RepoRefByType(git.RefTypeBranch), repo.SetEditorconfigIfExists, repo.Home) ``` When a PAT/OAuth2 token is supplied via HTTP Basic auth, `services/auth/basic.go` sets `IsApiToken = true` and records `ApiTokenScope`: ```go // services/auth/basic.go store.GetData()["IsApiToken"] = true store.GetData()["ApiTokenScope"] = token.Scope ``` The patched sibling handlers all call the web-side scope guard `context.CheckRepoScopedToken(...)`, which enforces both the public-only restriction and the `repository` scope: ``` routers/web/repo/download.go:23 (raw / media / archive) ← GHSA-cr4g routers/web/feed/render.go:15 (all repo feeds) ← GHSA-3pww routers/web/repo/attachment.go:190 (attachments / release assets, centralized) routers/web/repo/githttp.go:161 (git smart HTTP) ← GHSA-cc8w ``` `repo.Home` (`routers/web/repo/view_home.go:389`) performs **no** such check. Its only gate is `checkHomeCodeViewable`, which verifies the **user's** permission and that the code unit is enabled neither of which constrains the **token's** scope. The README, file listing, and sidebar are then rendered. (The `handleRepoHomeFeed` sub-path is guarded via `ShowRepoFeed`, but the HTML repo view is not.) ### Proof of Concept Reproduced against `gitea/gitea:main-nightly` (build `g2e1be0b114`, identical to the source commit above). A private repository `admin/secretrepo` is created, and a token is minted with **only** the `read:user` scope (no `repository` scope). ``` === anonymous baseline (repository is private) === anon GET /admin/secretrepo HTTP=404 === same no-repo-scope token across routes === API repo get (proves token lacks repo scope) HTTP=403 canary=0 /admin/secretrepo/archive/main.zip (control) HTTP=403 canary=0 /admin/secretrepo/raw/branch/main/README.md HTTP=403 canary=0 /admin/secretrepo.rss (control) HTTP=403 canary=0 /admin/secretrepo (repo.Home, VULN) HTTP=200 canary=1 ``` A second token with scope `public-only,read:repository` behaves identically: `/archive` → 403, but `/admin/secretrepo` → 200 and returns the private content. `canary=1` means the private README marker was returned in the HTML response; the private file name `SECRET.md` is also disclosed in the rendered file tree. Full self-contained reproducer (Docker, prints a PASS/FAIL verdict): ```bash #!/usr/bin/env bash set -euo pipefail N=gitea-poc; PW='Adm1n!pass99'; CANARY='TOP-SECRET-CANARY-9F3A2' docker rm -f $N >/dev/null 2>&1 || true docker run -d --name $N \ -e GITEA__security__INSTALL_LOCK=true -e GITEA__database__DB_TYPE=sqlite3 \ -e GITEA__server__ROOT_URL=http://localhost:3000/ \ -e GITEA__service__DISABLE_REGISTRATION=true \ -p 3000:3000 gitea/gitea:main-nightly >/dev/null for i in $(seq 1 40); do [ "$(curl -s -o /dev/null -w '%{http_code}' http://localhost:3000/api/healthz)" = 200 ] && break; sleep 2; done docker exec -u git $N gitea admin user create --admin --username admin \ --password "$PW" --email admin@example.com --must-change-password=false >/dev/null curl -s -u admin:"$PW" -X POST http://localhost:3000/api/v1/user/repos \ -H 'Content-Type: application/json' \ -d '{"name":"secretrepo","private":true,"auto_init":true,"default_branch":"main"}' >/dev/null SHA=$(curl -s -u admin:"$PW" http://localhost:3000/api/v1/repos/admin/secretrepo/contents/README.md \ | python3 -c "import json,sys;print(json.load(sys.stdin)['sha'])") curl -s -u admin:"$PW" -X PUT http://localhost:3000/api/v1/repos/admin/secretrepo/contents/README.md \ -H 'Content-Type: application/json' \ -d '{"content":"'"

### Impact `channelBinding=require` connections can be silently downgraded from `SCRAM-SHA-256-PLUS` (with channel binding) to plain `SCRAM-SHA-256` (without it), losing the man-in-the-middle protection the setting is meant to guarantee. An attacker who can intercept the TLS connection triggers the downgrade with a certificate whose signature algorithm has no `tls-server-end-point` channel-binding hash. Examples are `Ed25519`, `Ed448`, and post-quantum algorithms. Two issues combine in releases 42.7.4 through 42.7.11: 1. The bundled `com.ongres.scram:scram-client` (3.1 or 3.2) returns an empty byte array instead of failing when it cannot derive the binding hash for such a certificate. This is the library issue tracked as [GHSA-p9jg-fcr6-3mhf](https://github.com/ongres/scram/security/advisories/GHSA-p9jg-fcr6-3mhf). 2. pgJDBC does not enforce `channelBinding=require` where it matters. `ScramAuthenticator` checks only that the server *advertised* a `-PLUS` mechanism; it neither rejects the empty binding nor checks that the *negotiated* mechanism uses channel binding. The connection therefore downgrades silently, and would do so even against a fixed `scram-client`, because the missing enforcement is in pgJDBC's own code. Only connections that set `channelBinding=require` are affected. Under the default `prefer` policy, and under `allow` or `disable`, falling back to plain SCRAM is the documented behaviour. Releases before 42.7.4 are unaffected, because they do not support channel binding. ### Patches Fixed in pgJDBC 42.7.12. pgJDBC now enforces channel binding in its own code, independently of the `scram-client` version: - Under `channelBinding=require`, it fails the connection when no channel-binding data can be extracted from the server certificate, instead of passing an empty value to the SCRAM client. The error names the certificate signature algorithm. - After negotiation, it requires the selected mechanism to use channel binding (a `-PLUS` mechanism) whenever `channelBinding=require` is set, regardless of how negotiation resolved. Upgrade to 42.7.12 or later. ### Workarounds No pgJDBC setting restores channel-binding enforcement on an affected release; upgrading is the fix. If you cannot upgrade immediately, verify the server certificate at the TLS layer so that a man-in-the-middle cannot present a substitute certificate. Set `sslmode=verify-full` with a truststore that contains only your server's CA. This defence is independent of channel binding and blocks the same attacker. Connections that rely on `channelBinding=require` in place of certificate verification have no equivalent workaround and should upgrade. ### References - [GHSA-p9jg-fcr6-3mhf](https://github.com/ongres/scram/security/advisories/GHSA-p9jg-fcr6-3mhf) — the related `com.ongres.scram:scram-client` issue (root cause of the empty channel-binding value). - `scram-client` 3.3 release (library fix): https://github.com/ongres/scram/releases/tag/3.3 - pgJDBC fix in 42.7.12: [commit](https://github.com/pgjdbc/pgjdbc/commit/77df98e4e66c12936ded3478a0954f6f580bad99)

A malicious file identified by the SHA-256 hash 226d5f0493530a890fe642db959232b63ba8b7be48ea94a65cc68f8437b10ae5 was observed by OffSeq Mirage honeypot sensors on July 21, 2026. The file was involved in attacker activity using the T1105 technique (Ingress Tool Transfer) and was seen originating from attacker infrastructure in Great Britain. This hash corresponds to a specific malicious payload, which could be a dropper, web shell, miner, or post-exploitation tool. The file was observed twice during the specified date. There is no known exploit in the wild associated with this hash, and no affected software versions are identified.

A malicious file identified by the SHA-256 hash 980a7bfa9dd517f3b934f61e23d9e277bf222ce9b1cb055eecd1c7f87b35d7fc was observed twice in attacker activity on July 21, 2026. The file is associated with the MITRE ATT&CK technique T1105 (Ingress Tool Transfer), indicating it was used to stage or deliver a malicious payload such as a dropper, web shell, miner, or post-exploitation tool. The attacker infrastructure was located in Great Britain. This indicator should be matched against files in environments and security tools to detect potential compromise.