Ohne Bewertungosv:GHSA-m3qr-fvp4-78xj

    Arc has unauthenticated application log disclosure via `/api/v1/logs`

    Veröffentlicht Quellen: OSV

    Teilen

    Was ist betroffen, was ist zu tun

    Die vorliegenden Quellen nennen keine Fix-Version. Prüfen Sie die Herstellerhinweise in den Referenzen unten.

    Unklar, ob und wie Sie betroffen sind? Frage zu dieser Schwachstelle stellen

    Metriken

    —

    Priorität

    Für diese Schwachstelle liegt kein Wert vor.

    —

    CVSS v3

    Für diese Schwachstelle liegt kein Wert vor.

    —

    EPSS-Score

    Für diese Schwachstelle liegt kein Wert vor.

    Alle Metriken anzeigen
    Schweregrad
    Ohne Bewertung
    Priorität (0–325)

    Der Priorisierungs-Score ist eine zusammengeführte Kennzahl, die mehrere Einzelsignale zu einer einzigen, handlungsleitenden Rangfolge verdichtet: technische Schwere (CVSS), Ausnutzungswahrscheinlichkeit (EPSS), der Status als bekannt ausgenutzt (KEV) und der Kontext des betroffenen Assets. Ziel ist die Antwort auf die einzig wirklich wichtige Frage im Schwachstellenmanagement: Was zuerst?

    Im Glossar lesen
    30.00 Methodik
    Exploit-Reife

    Ein Exploit ist Code oder eine Technik, die eine konkrete Schwachstelle gezielt ausnutzt, um ein unbeabsichtigtes Verhalten zu erzwingen — etwa Code auszuführen oder Rechte auszuweiten. Er ist das Werkzeug, das aus einer theoretischen Lücke einen praktischen Angriff macht.

    Im Glossar lesen
    kein öffentlicher PoC bekannt
    KEV-Status

    Der KEV-Katalog ist eine von der US-Behörde CISA gepflegte Liste von Schwachstellen, für die eine aktive Ausnutzung in der Praxis nachgewiesen ist. Er beantwortet nicht die Frage „wie schwer?“, sondern „wird es bereits angegriffen?“ — und priorisiert damit das Patchen scharf.

    Im Glossar lesen
    —
    Veröffentlicht

    Einordnung nach NIS2 und CRA

    Regelbasierte Einordnung aus Ausnutzungsstatus und Schweregrad. Sie ersetzt keine Prüfung im Einzelfall.

    NIS2

    NIS2 ist die EU-Richtlinie (EU) 2022/2555 zur Erhöhung des Cybersicherheitsniveaus in der Union. Sie weitet Pflichten gegenüber der ersten NIS-Richtlinie deutlich aus: mehr Sektoren, verbindliches Risikomanagement, gestufte Meldepflichten und persönliche Verantwortung der Geschäftsleitung.

    Im Glossar lesen
    Behandeln Sie die Schwachstelle im regulären Schwachstellenmanagement nach Art. 21 Abs. 2 lit. e NIS2.
    CRA

    Der CRA ist die EU-Verordnung (EU) 2024/2847 mit horizontalen Cybersicherheitsanforderungen an „Produkte mit digitalen Elementen“ — von Industriesteuerungen über Software bis zu vernetzten Verbrauchergeräten. Erstmals müssen Hersteller Sicherheit über den gesamten Produktlebenszyklus gewährleisten, Schwachstellen behandeln und Sicherheitsupdates bereitstellen.

    Im Glossar lesen
    Ab dem 11.12.2027 verpflichtet Anhang I Teil II CRA Hersteller betroffener Produkte mit digitalen Elementen, Schwachstellen unverzüglich zu behandeln und Sicherheitsupdates bereitzustellen.
    ISO/IEC 27001

    ISO/IEC 27001 ist der international führende Standard für ein Informationssicherheits-Managementsystem (ISMS). Er beschreibt einen risikobasierten, prozessorientierten Rahmen, um Informationssicherheit systematisch zu planen, umzusetzen, zu überprüfen und zu verbessern.

    Im Glossar lesen
    Maßnahme A.8.8, Management technischer Schwachstellen: Relevanz für Ihre Systeme bewerten, Behebung einplanen und nachweisen.

    Beschreibung

    Summary

    Arc exposes GET /api/v1/logs without authentication even when authentication is enabled by default. The route is registered before the global Fiber authentication middleware, and the handler returns recent buffered application logs without performing its own authorization check.

    Details

    Arc applies the global auth middleware after calling server.RegisterRoutes():

    • cmd/arc/main.go:1598-1599 registers base routes via server.RegisterRoutes().
    • cmd/arc/main.go:1601-1618 configures and installs auth.NewMiddleware(...) later.

    server.RegisterRoutes() registers GET /api/v1/logs as a base route:

    • internal/api/server.go:164-183 registers base health, metrics, and logs routes, including s.app.Get("/api/v1/logs", s.logsHandler).

    The logs handler returns buffered logs without checking authentication or authorization:

    • internal/api/server.go:537-567 parses limit, level, and since_minutes, reads logger.GetBuffer().GetRecent(...), and returns JSON.
    • internal/logger/buffer.go:9-16 defines log entries returned to callers: timestamp, level, component, message, and caller.
    • internal/logger/buffer.go:33-39 creates a global log buffer holding the last 10,000 entries.
    • internal/api/server.go:540-558 permits up to limit=1000 and since_minutes=1440 in one unauthenticated request.

    Authentication is enabled by default and /api/v1/logs is not listed as a public route:

    • internal/config/config.go:841-843 defaults auth to enabled.
    • internal/auth/middleware.go:29-41 public defaults are /health, /ready, /api/v1/auth/verify, and /metrics prefix; /api/v1/logs is not public.

    However, Fiber route/middleware order makes the later middleware ineffective for an earlier exact route. Local verification against Fiber v2.52.13 showed a route registered before app.Use(...) returns 200 and the later middleware is not reached. Fiber’s router walks routes in declaration order and stops after the first matching route unless the handler calls c.Next(); logsHandler does not call c.Next().

    Proof of concept

    Safe local reproduction only; do not scan external infrastructure.

    1. Start Arc with default authentication enabled.
    2. Request logs without an Authorization header or x-api-key header:
    curl -i 'http://127.0.0.1:8000/api/v1/logs?limit=1000&since_minutes=1440'
    

    Expected vulnerable result:

    HTTP/1.1 200 OK
    Content-Type: application/json
    
    {"timestamp":"...","count":...,"logs":[...]}
    
    1. Compare with a protected endpoint without credentials:
    curl -i 'http://127.0.0.1:8000/api/v1/auth/tokens'
    

    Expected protected result:

    HTTP/1.1 401 Unauthorized
    

    This demonstrates that default auth is active while /api/v1/logs bypasses it due to registration order.

    Impact

    An unauthenticated network attacker can retrieve recent application logs. Depending on deployment and log level, logs can disclose operational metadata such as component names, internal paths, database/measurement names, node identifiers, caller locations, request outcomes, and error details. This can assist further attacks and may expose sensitive data if any deployment logs secrets or user-controlled confidential data.

    The audit did not confirm that the bootstrap admin token banner is captured by this endpoint; that banner is printed with fmt.Fprintf(os.Stderr, ...), while this endpoint reads the zerolog-backed application buffer.

    Workarounds

    Until patched, operators can restrict access to /api/v1/logs at a reverse proxy, firewall, ingress policy, or service mesh. If the endpoint is not needed, block it entirely.

    Suggested fix

    • Move /api/v1/logs registration after global auth middleware and require an authenticated administrator; or
    • Add explicit route-level middleware: auth.RequireAdmin(authManager) for /api/v1/logs; and
    • Add a regression test that unauthenticated requests to /api/v1/logs return 401/403 while /health and /ready remain public.

    References / evidence

    • cmd/arc/main.go:1598-1618
    • internal/api/server.go:164-183
    • internal/api/server.go:537-567
    • internal/auth/middleware.go:29-41
    • internal/config/config.go:841-843
    • internal/logger/buffer.go:9-16
    • internal/logger/buffer.go:33-39

    Quelle: OSV (Open Source Vulnerabilities)