Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
12 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/lin-snow/ech0 < 1.4.8-0.20260503040602-091d26d2d942
Fixed in
1.4.8-0.20260503040602-091d26d2d942· Vendor fix available
Issue
The fetchPeerConnectInfo function in internal/service/connect/connect.go:214-239 uses httpUtil.SendRequest (no SSRF protection) instead of SendSafeRequest (which has ValidatePublicHTTPURL with private IP blocking). This allows authenticated users to make the server request arbitrary URLs including internal/cloud metadata endpoints. Details In internal/service/connect/connect.go, the fetchPeerConnectInfo function: This uses SendRequest which has NO URL validation. The codebase HAS SendSafeRequest at internal/util/http/http.go:228-281 with proper SSRF protection, but fetchPeerConnectInfo does not use it. Called from: - Line 307: data, err := fetchPeerConnectInfo(conn.ConnectURL, requestTimeout) - - Line 498: data, err := fetchPeerConnectInfo(conn.ConnectURL, healthProbeTimeout) PoC Or for Kubernetes: Impact - Confidentiality: SSRF can access internal services, cloud metadata (AWS IMDSv1, GCE metadata), Kubernetes API - - CWE-918: Server-Side Request Forgery
Recommended action: Upgrade to 1.4.8-0.20260503040602-091d26d2d942 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/lin-snow/ech0 < 1.4.8-0.20260503040728-a7e8b8e84bd1
Fixed in
1.4.8-0.20260503040728-a7e8b8e84bd1· Vendor fix available
Issue
No authentication is required to invoke PUT /api/echo/like/:id. The handler is registered on the public router group. The service increments favcount for the given echo without checking identity, without a per-user limit, and without CSRF tokens. A remote client can arbitrarily inflate like metrics with repeated requests. Description Root cause: The like endpoint is explicitly public (PublicRouterGroup). LikeEcho in the service layer only runs a repository increment inside a transaction—no viewer/user binding. Security boundary that fails: Integrity of engagement metrics (likes) and any trust that “likes” represent distinct or authenticated users. Exploitation: Discover or guess a public echo UUID (timeline, API, share link) → send unauthenticated PUT repeatedly → favcount increases linearly. Affected files | Public route registration | internal/router/echo.go | | Like mutation (no auth check) | internal/service/echo/echo.go | | Handler | internal/handler/echo/echo.go |…
Recommended action: Upgrade to 1.4.8-0.20260503040728-a7e8b8e84bd1 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The file upload endpoint validates Content-Type using only the client-supplied multipart header, with no server-side content inspection or file extension validation. Combined with an unauthenticated static file server that determines Content-Type from file extension, this allows an admin to upload HTML/SVG files containing JavaScript that execute in the application's origin when visited by any user. Additionally, image/svg+xml is in the default allowed types, enabling stored XSS via SVG without any Content-Type spoofing. Details The upload handler at internal/service/file/file.go:85-87 validates file type using only the multipart Content-Type header: isAllowedType at file.go:836-843 performs exact string matching — no magic byte detection, no extension validation: The original file extension is preserved in the storage key by RandomKeyGenerator at internal/storage/keygen.go:41: All locally stored files are served publicly without authentication at…
Recommended action: Upgrade to 4.4.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The validateWebhookURL function in webhooksettingservice.go attempts to block webhooks targeting private/internal IP addresses, but only checks literal IP strings via net.ParseIP(). Hostnames that DNS-resolve to private IPs (e.g., 169.254.169.254.nip.io, 10.0.0.1.nip.io) bypass all checks, allowing an admin to create webhooks that make server-side requests to internal network services and cloud metadata endpoints. Details The vulnerability is in validateWebhookURL (internal/service/setting/webhooksettingservice.go:180-199): net.ParseIP("169.254.169.254.nip.io") returns nil because it is not a literal IP address. The entire private IP check block is skipped, and the function returns nil (valid). Both HTTP clients that execute webhook requests use standard http.Client / http.Transport with no custom DialContext to verify resolved IPs: - TestWebhook (webhooksettingservice.go:169): &http.Client{Timeout: 5 time.Second} - Dispatcher (dispatcher.go:51-58): &http.Client{...Transport:…
Recommended action: Upgrade to 4.4.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The system log endpoints (GET /api/system/logs, GET /api/system/logs/stream, WS /ws/system/logs) lack authorization checks, allowing any authenticated non-admin user to read and stream all server logs. These logs contain error stack traces, internal file paths, module names, and arbitrary structured fields that facilitate reconnaissance for further attacks. Details The dashboard routes in internal/router/dashboard.go:7-8 register log endpoints on the AuthRouterGroup without any RequireScopes middleware: Compare with other admin-only routes that properly use RequireScopes: The AuthRouterGroup only applies JWTAuthMiddleware() (router.go:36), which validates the JWT and sets the viewer context but does not check admin status. The WSRouterGroup (router.go:37) has no middleware at all — the WebSocket handler only calls ParseToken to verify the JWT signature (dashboard.go:74) without any role/scope validation. The handler (internal/handler/dashboard/dashboard.go:29-62) and service…
Recommended action: Upgrade to 4.4.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
All 9 comment panel admin endpoints (/api/panel/comments/) are missing RequireScopes() middleware, while every other admin endpoint in the application enforces scope-based authorization on access tokens. An admin-issued access token scoped to minimal permissions (e.g., echo:read only) can perform full comment moderation operations including listing, approving, rejecting, deleting comments, and modifying comment system settings. Details The access token scope enforcement system works as follows: JWTAuthMiddleware (internal/middleware/auth.go) parses any valid JWT and injects a viewer into the request context. The RequireScopes() middleware (internal/middleware/scope.go:14) then checks whether the token is an access token and, if so, validates that it carries the required scopes. Session tokens are passed through without scope checks (by design — sessions represent full user authority). Every admin route group applies RequireScopes() per-handler: - internal/router/echo.go —…
Recommended action: Upgrade to 4.4.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The PUT /user endpoint is protected by RequireScopes("profile:read"), which is a read-only scope. However, the endpoint performs write operations including password changes. An attacker who obtains an admin's restricted profile:read access token can change the admin's password, then login to receive an unrestricted session token that bypasses all scope enforcement. Details The scope enforcement system defines granular scopes (e.g., echo:read, echo:write, admin:user) but has no profile:write scope. The PUT /user route is protected only by profile:read: The RequireScopes middleware bypasses all scope checks for session tokens, and for access tokens only verifies the token contains the listed scopes: The UpdateUser service checks user.IsAdmin but does not verify the token's scope is sufficient for write operations: After the password is changed, the attacker logs in via POST /login which calls issueUserToken → CreateClaims, producing a session token with Type: "session"…
Recommended action: Upgrade to 4.4.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Ech0 allows any authenticated user to read historical system logs and subscribe to live log streams because the dashboard log endpoints validate only that a JWT is present and valid, but do not require an administrator role or privileged scope. Impact Any valid user session can access GET /api/system/logs and can also connect to the SSE and WebSocket log streaming endpoints. This exposes operational log data to low-privilege users. Depending on deployment and logging practices, the returned logs may include internal file paths, stack traces, admin activity, background job output, internal URLs, and other sensitive operational context. This creates a post-authentication information disclosure primitive that can materially aid follow-on attacks. Details The issue is caused by an authorization gap between route registration, handler logic, and the service layer. internal/router/dashboard.go registers the log endpoints on authenticated router groups, but does not apply any…
Recommended action: Upgrade to 4.3.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Ech0 scoped access tokens do not reliably enforce least privilege: multiple privileged admin routes omit scope checks, and the backup export handler strips token scope metadata entirely, allowing a low-scope admin access token to reach broader admin functionality than intended. Impact An attacker who obtains a deliberately limited access token for an admin account can use that token to access privileged functionality outside its assigned scope. Confirmed impact includes access to /api/inbox with a token scoped only for echo:read and successful backup export via /api/backup/export?token=..., which returns a full ZIP archive. In practice, this turns a narrowly delegated API token into a broader privileged access and data exfiltration primitive. Details The issue is caused by a split authorization model: - JWTAuthMiddleware() authenticates the token and stores scope metadata in the viewer context - RequireScopes(...) enforces least privilege, but only when a route explicitly…
Recommended action: Upgrade to 4.3.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/lin-snow/ech0 < 1.4.8-0.20260401031029-4ca56fea5ba4
Fixed in
1.4.8-0.20260401031029-4ca56fea5ba4· Vendor fix available
Issue
The GET /api/website/title endpoint accepts an arbitrary URL via the websiteurl query parameter and makes a server-side HTTP request to it without any validation of the target host or IP address. The endpoint requires no authentication. An attacker can use this to reach internal network services, cloud metadata endpoints (169.254.169.254), and localhost-bound services, with partial response data exfiltrated via the HTML <title tag extraction. Details The vulnerability exists in the interaction between four components: 1. Route registration — no authentication (internal/router/common.go:11): The PublicRouterGroup is created at internal/router/router.go:34 as r.Group("/api") with no auth middleware attached (unlike AuthRouterGroup which uses JWTAuthMiddleware). 2. Handler — no input validation (internal/handler/common/common.go:106-127): The DTO (internal/model/common/commondto.go:155-156) only enforces binding:"required" — no URL scheme or host validation. 3. Service — TrimURL…
Recommended action: Upgrade to 1.4.8-0.20260401031029-4ca56fea5ba4 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/lin-snow/ech0 < 1.4.8-0.20260401031029-4ca56fea5ba4
Fixed in
1.4.8-0.20260401031029-4ca56fea5ba4· Vendor fix available
Issue
Ech0 implements link preview (editor fetches a page title) through GET /api/website/title. That is legitimate product behavior, but the implementation is unsafe: the route is unauthenticated, accepts a fully attacker-controlled URL, performs a server-side GET, reads the entire response body into memory (io.ReadAll). There is no host allowlist, no SSRF filter, and InsecureSkipVerify: true on the outbound client. Attacker outcome : Anyone who can reach the instance can force the Ech0 server to open HTTP/HTTPS URLs of their choice as seen from the server’s network position (Docker bridge, VPC, localhost from the process view). Go’s default http.Client follows redirects (unless disabled). Redirect chains can move the server-side request from an allowed-looking host to an internal target; the code does not disable this in SendRequest. Affected Components Ech0 codebase: - internal/handler/common/common.go Handles the /api/website/title endpoint and accepts user-controlled URL…
Recommended action: Upgrade to 1.4.8-0.20260401031029-4ca56fea5ba4 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/lin-snow/ech0 < 1.4.8-0.20260322121226-acbf1fd71011
Fixed in
1.4.8-0.20260322121226-acbf1fd71011· Vendor fix available
Issue
A public access-control flaw allows unauthenticated users to retrieve the full user list from GET /api/allusers. This exposes user profile metadata to anyone who can reach the application and enables remote user enumeration. Details The vulnerable route is registered as a public endpoint: - internal/router/user.go:17 - appRouterGroup.PublicRouterGroup.GET("/allusers", h.UserHandler.GetAllUsers()) However, the handler appears to have been intended as an authenticated endpoint: - internal/handler/user/user.go:177-185 - API annotations indicate an authentication requirement via @Security ApiKeyAuth This creates a mismatch between the documented security model and the actual routing configuration. As a result, requests to GET /api/allusers succeed without authentication and return user records, including profile metadata such as usernames, email addresses, role-related flags, avatar values, and locale information. A negative control against another endpoint that correctly…
Recommended action: Upgrade to 1.4.8-0.20260322121226-acbf1fd71011 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.