GHSA-VRHC-JJFC-M3M3

Vulnerability from github – Published: 2026-07-21 21:02 – Updated: 2026-07-21 21:02

Summary

Gitea: OAuth2 sign-in reactivates an administrator-deactivated account on auth sources without refresh tokens (incomplete fix of #38009)

Details

Description

Gitea's OAuth2 sign-in callback reactivates a deactivated user account (IsActive=false) when the user signs in through an authentication source that does not issue refresh tokens (notably GitHub, and any OIDC/OAuth2 source configured without offline_access). PR #38009 added a gate intended to reactivate users only when the OAuth2 auto-sync cron had disabled them, using "the stored refresh token is empty" as the signal. That signal is wrong: for sources that never issue refresh tokens, an empty refresh token is the normal state of every user, so the gate cannot distinguish a cron-disabled account from one an administrator deliberately deactivated. The next time the administrator-deactivated user signs in through the provider, Gitea sets IsActive=true and grants a full session, silently undoing the administrator's action. This is the exact behavior #38009 was written to prevent. (ProhibitLogin, the hard ban, is enforced separately and is not affected.)

No special privileges are required beyond being the deactivated user and being able to sign in through the source.

Root Cause

routers/web/auth/oauth.go (the handleOAuth2SignIn reactivation gate):

if !u.IsActive {
    extLogin, hasExt, err := user_model.GetExternalLogin(ctx, authSource.ID, gothUser.UserID)
    if err != nil { ctx.ServerError("GetExternalLogin", err); return }
    isDisabledByAutoSync := hasExt && extLogin.RefreshToken == ""   // wrong signal
    if isDisabledByAutoSync {
        opts.IsActive = optional.Some(true)                          // reactivates the account
    }
}

The assumption that RefreshToken == "" is produced only by the auto-sync cron is false:

The cron's disable path is unreachable for sources without refresh tokens. services/auth/source/oauth2/source_sync.go returns early: if !provider.RefreshTokenAvailable() { return ... }, so it never disables (or touches the tokens of) such users.
The stored token is exactly what the provider returned, with no synthesizing: services/externalaccount/user.go stores RefreshToken: gothUser.RefreshToken. When the provider issues none, this is "" from the first login.
GitHub never issues a refresh token: goth hardcodes func (p *Provider) RefreshTokenAvailable() bool { return false } (providers/github/github.go). OIDC/OAuth2 without offline_access likewise store "".

So for a GitHub (or no-refresh-token) source, RefreshToken == "" is the state of every user, including one an administrator deactivated, and the gate reactivates them.

Proof of Concept

Setup: - A Gitea instance with a GitHub authentication source (Admin Panel -> Authentication Sources -> OAuth2 -> GitHub), or any OAuth2/OIDC source configured without offline_access. - Account V: a normal user who has signed in at least once through that source (an external_login_user row exists with empty refresh_token).

Steps: 1. As an administrator, open Admin Panel -> Users -> V and uncheck "Activated" (is_active=false). Confirm V's requests now bounce to the activation page. 2. As V, sign in again via "Sign in with GitHub" and complete the provider flow. 3. V lands in the application with a working session. SELECT is_active FROM "user" WHERE lower_name='v'; now returns true.

Expected (intended by #38009): V stays is_active=false and is routed to the activation page. Actual: V is is_active=true with a full session — the administrator's deactivation is undone.

- GitHub user, ADMIN deactivated                 refreshToken=""    -> REACTIVATED + session granted   <<< admin action undone
- OIDC user w/ refresh token, ADMIN deactivated  refreshToken="..." -> stays disabled  (control)
- OIDC user, AUTO-SYNC cron disabled             refreshToken=""    -> REACTIVATED (intended)
RESULT: BYPASS CONFIRMED.

Gitea's own regression test TestOAuth2CallbackReactivationGating ("auto-sync-disabled user is reactivated") sets RefreshToken="" and asserts reactivation after a full OIDC callback — that state is identical to a GitHub-source user an administrator deactivated.

Impact

Any Gitea instance using a GitHub authentication source (one of the most common) or an OIDC/OAuth2 source without refresh tokens, that relies on the "Activated" toggle to disable accounts, is affected. A deactivated user restores their own account to active and obtains a session, regaining whatever access the account had. Deactivation does not clear IsAdmin, so a deactivated administrator regains admin access. Bound: accounts disabled with "Prohibit Login" stay blocked; this defeats the IsActive=false deactivation only.

Severity

8.1 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.gitea.io/gitea"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.27.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55987"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T21:02:10Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Description\n\nGitea\u0027s OAuth2 sign-in callback reactivates a deactivated user account (`IsActive=false`) when the user signs in through an authentication source that does not issue refresh tokens (notably GitHub, and any OIDC/OAuth2 source configured without `offline_access`). PR #38009 added a gate intended to reactivate users only when the OAuth2 auto-sync cron had disabled them, using \"the stored refresh token is empty\" as the signal. That signal is wrong: for sources that never issue refresh tokens, an empty refresh token is the normal state of every user, so the gate cannot distinguish a cron-disabled account from one an administrator deliberately deactivated. The next time the administrator-deactivated user signs in through the provider, Gitea sets `IsActive=true` and grants a full session, silently undoing the administrator\u0027s action. This is the exact behavior #38009 was written to prevent. (`ProhibitLogin`, the hard ban, is enforced separately and is not affected.)\n\nNo special privileges are required beyond being the deactivated user and being able to sign in through the source.\n\n### Root Cause\n\n`routers/web/auth/oauth.go` (the `handleOAuth2SignIn` reactivation gate):\n\n```go\nif !u.IsActive {\n    extLogin, hasExt, err := user_model.GetExternalLogin(ctx, authSource.ID, gothUser.UserID)\n    if err != nil { ctx.ServerError(\"GetExternalLogin\", err); return }\n    isDisabledByAutoSync := hasExt \u0026\u0026 extLogin.RefreshToken == \"\"   // wrong signal\n    if isDisabledByAutoSync {\n        opts.IsActive = optional.Some(true)                          // reactivates the account\n    }\n}\n```\n\nThe assumption that `RefreshToken == \"\"` is produced only by the auto-sync cron is false:\n\n- The cron\u0027s disable path is unreachable for sources without refresh tokens. `services/auth/source/oauth2/source_sync.go` returns early: `if !provider.RefreshTokenAvailable() { return ... }`, so it never disables (or touches the tokens of) such users.\n- The stored token is exactly what the provider returned, with no synthesizing: `services/externalaccount/user.go` stores `RefreshToken: gothUser.RefreshToken`. When the provider issues none, this is `\"\"` from the first login.\n- GitHub never issues a refresh token: `goth` hardcodes `func (p *Provider) RefreshTokenAvailable() bool { return false }` (`providers/github/github.go`). OIDC/OAuth2 without `offline_access` likewise store `\"\"`.\n\nSo for a GitHub (or no-refresh-token) source, `RefreshToken == \"\"` is the state of every user, including one an administrator deactivated, and the gate reactivates them.\n\n### Proof of Concept\n\nSetup:\n- A Gitea instance with a GitHub authentication source (Admin Panel -\u003e Authentication Sources -\u003e OAuth2 -\u003e GitHub), or any OAuth2/OIDC source configured without `offline_access`.\n- Account V: a normal user who has signed in at least once through that source (an `external_login_user` row exists with empty `refresh_token`).\n\nSteps:\n1. As an administrator, open Admin Panel -\u003e Users -\u003e V and uncheck \"Activated\" (`is_active=false`). Confirm V\u0027s requests now bounce to the activation page.\n2. As V, sign in again via \"Sign in with GitHub\" and complete the provider flow.\n3. V lands in the application with a working session. `SELECT is_active FROM \"user\" WHERE lower_name=\u0027v\u0027;` now returns `true`.\n\nExpected (intended by #38009): V stays `is_active=false` and is routed to the activation page.\nActual: V is `is_active=true` with a full session \u2014 the administrator\u0027s deactivation is undone.\n\n```\n- GitHub user, ADMIN deactivated                 refreshToken=\"\"    -\u003e REACTIVATED + session granted   \u003c\u003c\u003c admin action undone\n- OIDC user w/ refresh token, ADMIN deactivated  refreshToken=\"...\" -\u003e stays disabled  (control)\n- OIDC user, AUTO-SYNC cron disabled             refreshToken=\"\"    -\u003e REACTIVATED (intended)\nRESULT: BYPASS CONFIRMED.\n```\n\nGitea\u0027s own regression test `TestOAuth2CallbackReactivationGating` (\"auto-sync-disabled user is reactivated\") sets `RefreshToken=\"\"` and asserts reactivation after a full OIDC callback \u2014 that state is identical to a GitHub-source user an administrator deactivated.\n\n### Impact\n\nAny Gitea instance using a GitHub authentication source (one of the most common) or an OIDC/OAuth2 source without refresh tokens, that relies on the \"Activated\" toggle to disable accounts, is affected. A deactivated user restores their own account to active and obtains a session, regaining whatever access the account had. Deactivation does not clear `IsAdmin`, so a deactivated administrator regains admin access. Bound: accounts disabled with \"Prohibit Login\" stay blocked; this defeats the `IsActive=false` deactivation only.",
  "id": "GHSA-vrhc-jjfc-m3m3",
  "modified": "2026-07-21T21:02:10Z",
  "published": "2026-07-21T21:02:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-vrhc-jjfc-m3m3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-gitea/gitea"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/releases/tag/v1.27.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Gitea: OAuth2 sign-in reactivates an administrator-deactivated account on auth sources without refresh tokens (incomplete fix of #38009)"
}

GHSA-VRMH-5MMX-HJWX

Vulnerability from github – Published: 2026-06-10 13:39 – Updated: 2026-06-26 21:29

Summary

Nezha's private services (`EnableShowInService: false`) are enumerable via per-server endpoints, leaking name and timing data

Details

Private services (`EnableShowInService: false`) are enumerable via per-server endpoints, leaking name and timing data

CWE: CWE-285 (Improper Authorization) via CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) and CWE-863 (Incorrect Authorization — inconsistent gating across data-reader paths)

CVSS v3.1: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N → 5.3 (Medium)

Summary

The EnableShowInService flag on a Service is meant to gate that service's visibility from the public dashboard. The main service-listing endpoint (GET /api/v1/service → showService) correctly filters services with EnableShowInService: false via ServiceSentinel.CopyStats() (service/singleton/servicesentinel.go:421-438). However, two adjacent reader endpoints retrieve service objects through code paths that do not honor the same flag:

GET /api/v1/server/:id/service (listServerServices) iterates ServiceSentinel.GetSortedList() (which returns every service regardless of visibility) and emits service ID, name, and timing data for any service monitoring the queried server.
GET /api/v1/service/:id/history (getServiceHistory) calls ServiceSentinel.Get(serviceID) directly and emits the service name (and aggregated per-server stats for servers the viewer can see).

Both endpoints are mounted on the optionalAuth group, so an unauthenticated visitor can enumerate hidden services as long as they can guess a public server ID (linear scan over a small numeric ID space) or a service ID (likewise). The service owner's intent — "hide this from the public" via EnableShowInService: false — is silently bypassed.

Affected

nezha master at HEAD 636f4a99e6c3d8d75f17fdf7ad55d4ee0f73f1c0 (the audit checkout)
All recent 2.x releases that share this code path (post the EnableShowInService filter introduction at CopyStats)

Vulnerability details

[A] — single-source-of-truth filter exists at the listing site

service/singleton/servicesentinel.go:421-438:

func (ss *ServiceSentinel) CopyStats() map[uint64]model.ServiceResponseItem {
    var stats map[uint64]*serviceResponseItem
    copier.Copy(&stats, ss.LoadStats())

    sri := make(map[uint64]model.ServiceResponseItem)
    for k, service := range stats {
        if !service.service.EnableShowInService {       // [A] filter here
            delete(stats, k)
            continue
        }
        service.ServiceName = service.service.Name
        sri[k] = service.ServiceResponseItem
    }
    return sri
}

CopyStats() is the only reader that respects EnableShowInService. Get() and GetSortedList() immediately below it return the raw services with no such filter:

func (ss *ServiceSentinel) Get(id uint64) (s *model.Service, ok bool) {
    ss.servicesLock.RLock(); defer ss.servicesLock.RUnlock()
    s, ok = ss.services[id]
    return                                              // [A'] no EnableShowInService check
}

[B] — `listServerServices` iterates `GetSortedList()` and emits hidden services

cmd/dashboard/controller/service.go:258-340 (GET /api/v1/server/:id/service):

func listServerServices(c *gin.Context) ([]*model.ServiceInfos, error) {
    // ... server existence + userCanViewServer check ...
    services := singleton.ServiceSentinelShared.GetSortedList()      // [B] all services, no filter

    for _, service := range services {
        if service.Cover == model.ServiceCoverAll {
            if service.SkipServers[serverID] { continue }
        } else {
            if !service.SkipServers[serverID] { continue }
        }
        // ... fetch history ...
        infos := &model.ServiceInfos{
            ServiceID:   service.ID,
            ServerID:    serverID,
            ServiceName: service.Name,                  // [B'] leaked
            ServerName:  server.Name,
            // ... timing data ...
        }
        result = append(result, infos)
    }
    return result, nil
}

The DB-fallback path at queryServerServicesFromDB (service.go:340-) has the same structure: iterates services (the same GetSortedList() output) and emits ServiceName for any service monitoring serverID.

[C] — `getServiceHistory` returns the service name for any ID

cmd/dashboard/controller/service.go:126-180 (GET /api/v1/service/:id/history):

func getServiceHistory(c *gin.Context) (*model.ServiceHistoryResponse, error) {
    serviceID, _ := strconv.ParseUint(c.Param("id"), 10, 64)
    service, ok := singleton.ServiceSentinelShared.Get(serviceID)   // [C] no filter
    if !ok || service == nil {
        return nil, singleton.Localizer.ErrorT("service not found")
    }
    // period restriction for guests (1d only) — but the service exists,
    // and ServiceName is set unconditionally:
    response := &model.ServiceHistoryResponse{
        ServiceID:   serviceID,
        ServiceName: service.Name,                       // [C'] leaked
        Servers:     make([]model.ServerServiceStats, 0),
    }
    // ... per-server data is filtered via userCanViewServer — that part is correct ...
    return response, nil
}

The per-server data inside the response IS correctly filtered via userCanViewServer. The service NAME is not.

The mismatch

[A] (CopyStats) gates by EnableShowInService because that's the listing endpoint's contract. [A'] (Get) / GetSortedList() return the raw data because they're "internal" accessors. But [B] and [C] are public-reachable endpoints that use those raw accessors and emit identifying information about services the owner marked as private. The visibility flag exists; it just isn't enforced at every reader of the same data.

A correct guard would either: - Move the EnableShowInService filter into Get() / GetSortedList() themselves, gated by "caller is admin or service owner" - Re-check EnableShowInService at every endpoint that emits service identity (name/id/timing)

Proof of concept

Setup (any nezha 2.x deployment): 1. User A (member) creates a Service "Internal-CRM-Health" with EnableShowInService: false, monitoring server S which is public (HideForGuest: false). 2. The service does not appear in GET /api/v1/service (the main listing correctly hides it).

Enumeration as an unauthenticated guest:

# Find services that monitor server S
curl -s 'https://nezha.example/api/v1/server/'"$S_ID"'/service'
# →
# {"success":true,"data":[
#   {"service_id":42,"server_id":1,"service_name":"Internal-CRM-Health","server_name":"web-01",
#    "display_index":0,"created_at":[...],"avg_delay":[...]}
# ]}
#
# Hidden service is leaked: ID, name, and per-server timing data are all visible.

Confirmation via the second endpoint:

curl -s 'https://nezha.example/api/v1/service/42/history?period=1d'
# →
# {"success":true,"data":{
#   "service_id":42,
#   "service_name":"Internal-CRM-Health",  ← leaked even for direct ID lookup
#   "servers":[]                            ← per-server data correctly hidden
# }}

A scripted enumeration over public server IDs (a low-cardinality numeric space — typical nezha deployments have <1000 servers) trivially recovers the full set of hidden services that monitor any public server, along with their names and timing patterns.

Impact

Direct

Service names in nezha deployments are frequently descriptive of the underlying business asset they monitor: "Production CRM Monitor", "Internal Wiki Health", "Backup-Vault Connectivity", "Stripe Webhook Latency". The leak therefore:

Discloses the existence and purpose of internal services that the owner explicitly hid from the public dashboard.
Exposes timing/latency data for the monitored relationship between a private service and any public server it touches — sufficient for a competitor or attacker to infer business activity patterns, outage windows, and probable backend topology.
Confirms presence/absence of a service ID via the second endpoint — an oracle that lets an unauthenticated visitor enumerate the service-id namespace and learn the deployment's service count and naming convention even when no public servers exist as enumeration vectors.

Indirect / second-order

Affects multi-tenant public dashboards: nezha is frequently deployed as a public status page with a private "internal" tier in the same dashboard. The bypass collapses the privacy boundary between these tiers.
Composability with prior advisories: the recent fixes for GHSA-rxf6-wjh4-jfj6 (cross-user trigger-task firing), GHSA-hvv7-hfrh-7gxj (WS server-stream cross-tenant leak), and GHSA-4g6j-g789-rghm (forged monitor results) all address the cross-tenant visibility model. This finding is a sibling that closes one more reader gap in the same model.

Suggested fix

Either of:

Centralize the filter in ServiceSentinel — change Get(id) and GetSortedList() to accept the *gin.Context (or a viewer context) and apply the EnableShowInService filter plus an admin-or-owner override. This guarantees every reader inherits the gate:

go func (ss *ServiceSentinel) GetForViewer(c *gin.Context, id uint64) (*model.Service, bool) { s, ok := ss.Get(id) if !ok { return nil, false } if !s.EnableShowInService && !callerIsAdminOrOwns(c, s) { return nil, false } return s, true }

Recheck at every endpoint that emits service identity — add the EnableShowInService + ownership check at the top of listServerServices, getServiceHistory, and anywhere else GetSortedList()/Get() results flow to a response. More surgical but easier to miss next time.

Option (1) is symmetric with how userCanViewServer centralizes the server-visibility decision; the same pattern at the service layer would close this class once.

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/nezhahq/nezha"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.0.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-49397"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-10T13:39:24Z",
    "nvd_published_at": "2026-06-12T22:16:51Z",
    "severity": "MODERATE"
  },
  "details": "# Private services (`EnableShowInService: false`) are enumerable via per-server endpoints, leaking name and timing data\n\n**CWE**: CWE-285 (Improper Authorization) via CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) and CWE-863 (Incorrect Authorization \u2014 inconsistent gating across data-reader paths)\n\n**CVSS v3.1**: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N` \u2192 5.3 (Medium)\n\n## Summary\n\nThe `EnableShowInService` flag on a `Service` is meant to gate that service\u0027s visibility from the public dashboard. The main service-listing endpoint (`GET /api/v1/service` \u2192 `showService`) correctly filters services with `EnableShowInService: false` via `ServiceSentinel.CopyStats()` (`service/singleton/servicesentinel.go:421-438`). However, two adjacent reader endpoints retrieve service objects through code paths that do not honor the same flag:\n\n- `GET /api/v1/server/:id/service` (`listServerServices`) iterates `ServiceSentinel.GetSortedList()` (which returns every service regardless of visibility) and emits service ID, name, and timing data for any service monitoring the queried server.\n- `GET /api/v1/service/:id/history` (`getServiceHistory`) calls `ServiceSentinel.Get(serviceID)` directly and emits the service name (and aggregated per-server stats for servers the viewer can see).\n\nBoth endpoints are mounted on the `optionalAuth` group, so an unauthenticated visitor can enumerate hidden services as long as they can guess a public server ID (linear scan over a small numeric ID space) or a service ID (likewise). The service owner\u0027s intent \u2014 \"hide this from the public\" via `EnableShowInService: false` \u2014 is silently bypassed.\n\n## Affected\n\n- nezha `master` at HEAD `636f4a99e6c3d8d75f17fdf7ad55d4ee0f73f1c0` (the audit checkout)\n- All recent 2.x releases that share this code path (post the `EnableShowInService` filter introduction at `CopyStats`)\n\n## Vulnerability details\n\n### [A] \u2014 single-source-of-truth filter exists at the listing site\n\n`service/singleton/servicesentinel.go:421-438`:\n\n```go\nfunc (ss *ServiceSentinel) CopyStats() map[uint64]model.ServiceResponseItem {\n    var stats map[uint64]*serviceResponseItem\n    copier.Copy(\u0026stats, ss.LoadStats())\n\n    sri := make(map[uint64]model.ServiceResponseItem)\n    for k, service := range stats {\n        if !service.service.EnableShowInService {       // [A] filter here\n            delete(stats, k)\n            continue\n        }\n        service.ServiceName = service.service.Name\n        sri[k] = service.ServiceResponseItem\n    }\n    return sri\n}\n```\n\n`CopyStats()` is the only reader that respects `EnableShowInService`. `Get()` and `GetSortedList()` immediately below it return the raw services with no such filter:\n\n```go\nfunc (ss *ServiceSentinel) Get(id uint64) (s *model.Service, ok bool) {\n    ss.servicesLock.RLock(); defer ss.servicesLock.RUnlock()\n    s, ok = ss.services[id]\n    return                                              // [A\u0027] no EnableShowInService check\n}\n```\n\n### [B] \u2014 `listServerServices` iterates `GetSortedList()` and emits hidden services\n\n`cmd/dashboard/controller/service.go:258-340` (`GET /api/v1/server/:id/service`):\n\n```go\nfunc listServerServices(c *gin.Context) ([]*model.ServiceInfos, error) {\n    // ... server existence + userCanViewServer check ...\n    services := singleton.ServiceSentinelShared.GetSortedList()      // [B] all services, no filter\n\n    for _, service := range services {\n        if service.Cover == model.ServiceCoverAll {\n            if service.SkipServers[serverID] { continue }\n        } else {\n            if !service.SkipServers[serverID] { continue }\n        }\n        // ... fetch history ...\n        infos := \u0026model.ServiceInfos{\n            ServiceID:   service.ID,\n            ServerID:    serverID,\n            ServiceName: service.Name,                  // [B\u0027] leaked\n            ServerName:  server.Name,\n            // ... timing data ...\n        }\n        result = append(result, infos)\n    }\n    return result, nil\n}\n```\n\nThe DB-fallback path at `queryServerServicesFromDB` (`service.go:340-`) has the same structure: iterates `services` (the same `GetSortedList()` output) and emits ServiceName for any service monitoring `serverID`.\n\n### [C] \u2014 `getServiceHistory` returns the service name for any ID\n\n`cmd/dashboard/controller/service.go:126-180` (`GET /api/v1/service/:id/history`):\n\n```go\nfunc getServiceHistory(c *gin.Context) (*model.ServiceHistoryResponse, error) {\n    serviceID, _ := strconv.ParseUint(c.Param(\"id\"), 10, 64)\n    service, ok := singleton.ServiceSentinelShared.Get(serviceID)   // [C] no filter\n    if !ok || service == nil {\n        return nil, singleton.Localizer.ErrorT(\"service not found\")\n    }\n    // period restriction for guests (1d only) \u2014 but the service exists,\n    // and ServiceName is set unconditionally:\n    response := \u0026model.ServiceHistoryResponse{\n        ServiceID:   serviceID,\n        ServiceName: service.Name,                       // [C\u0027] leaked\n        Servers:     make([]model.ServerServiceStats, 0),\n    }\n    // ... per-server data is filtered via userCanViewServer \u2014 that part is correct ...\n    return response, nil\n}\n```\n\nThe per-server data inside the response IS correctly filtered via `userCanViewServer`. The service NAME is not.\n\n### The mismatch\n\n[A] (`CopyStats`) gates by `EnableShowInService` because that\u0027s the listing endpoint\u0027s contract. [A\u0027] (`Get`) / `GetSortedList()` return the raw data because they\u0027re \"internal\" accessors. But [B] and [C] are public-reachable endpoints that use those raw accessors and emit identifying information about services the owner marked as private. The visibility flag exists; it just isn\u0027t enforced at every reader of the same data.\n\nA correct guard would either:\n- Move the `EnableShowInService` filter into `Get()` / `GetSortedList()` themselves, gated by \"caller is admin or service owner\"\n- Re-check `EnableShowInService` at every endpoint that emits service identity (name/id/timing)\n\n## Proof of concept\n\nSetup (any nezha 2.x deployment):\n1. User A (member) creates a Service \"Internal-CRM-Health\" with `EnableShowInService: false`, monitoring server `S` which is public (`HideForGuest: false`).\n2. The service does not appear in `GET /api/v1/service` (the main listing correctly hides it).\n\nEnumeration as an unauthenticated guest:\n\n```bash\n# Find services that monitor server S\ncurl -s \u0027https://nezha.example/api/v1/server/\u0027\"$S_ID\"\u0027/service\u0027\n# \u2192\n# {\"success\":true,\"data\":[\n#   {\"service_id\":42,\"server_id\":1,\"service_name\":\"Internal-CRM-Health\",\"server_name\":\"web-01\",\n#    \"display_index\":0,\"created_at\":[...],\"avg_delay\":[...]}\n# ]}\n#\n# Hidden service is leaked: ID, name, and per-server timing data are all visible.\n```\n\nConfirmation via the second endpoint:\n\n```bash\ncurl -s \u0027https://nezha.example/api/v1/service/42/history?period=1d\u0027\n# \u2192\n# {\"success\":true,\"data\":{\n#   \"service_id\":42,\n#   \"service_name\":\"Internal-CRM-Health\",  \u2190 leaked even for direct ID lookup\n#   \"servers\":[]                            \u2190 per-server data correctly hidden\n# }}\n```\n\nA scripted enumeration over public server IDs (a low-cardinality numeric space \u2014 typical nezha deployments have \u003c1000 servers) trivially recovers the full set of hidden services that monitor any public server, along with their names and timing patterns.\n\n## Impact\n\n### Direct\n\nService names in nezha deployments are frequently descriptive of the underlying business asset they monitor: `\"Production CRM Monitor\"`, `\"Internal Wiki Health\"`, `\"Backup-Vault Connectivity\"`, `\"Stripe Webhook Latency\"`. The leak therefore:\n\n- **Discloses the existence and purpose of internal services** that the owner explicitly hid from the public dashboard.\n- **Exposes timing/latency data** for the monitored relationship between a private service and any public server it touches \u2014 sufficient for a competitor or attacker to infer business activity patterns, outage windows, and probable backend topology.\n- **Confirms presence/absence of a service ID** via the second endpoint \u2014 an oracle that lets an unauthenticated visitor enumerate the service-id namespace and learn the deployment\u0027s service count and naming convention even when no public servers exist as enumeration vectors.\n\n### Indirect / second-order\n\n- **Affects multi-tenant public dashboards**: nezha is frequently deployed as a public status page with a private \"internal\" tier in the same dashboard. The bypass collapses the privacy boundary between these tiers.\n- **Composability with prior advisories**: the recent fixes for `GHSA-rxf6-wjh4-jfj6` (cross-user trigger-task firing), `GHSA-hvv7-hfrh-7gxj` (WS server-stream cross-tenant leak), and `GHSA-4g6j-g789-rghm` (forged monitor results) all address the cross-tenant visibility model. This finding is a sibling that closes one more reader gap in the same model.\n\n## Suggested fix\n\nEither of:\n\n1. **Centralize the filter in `ServiceSentinel`** \u2014 change `Get(id)` and `GetSortedList()` to accept the `*gin.Context` (or a viewer context) and apply the `EnableShowInService` filter plus an admin-or-owner override. This guarantees every reader inherits the gate:\n\n   ```go\n   func (ss *ServiceSentinel) GetForViewer(c *gin.Context, id uint64) (*model.Service, bool) {\n       s, ok := ss.Get(id)\n       if !ok { return nil, false }\n       if !s.EnableShowInService \u0026\u0026 !callerIsAdminOrOwns(c, s) {\n           return nil, false\n       }\n       return s, true\n   }\n   ```\n\n2. **Recheck at every endpoint that emits service identity** \u2014 add the EnableShowInService + ownership check at the top of `listServerServices`, `getServiceHistory`, and anywhere else `GetSortedList()`/`Get()` results flow to a response. More surgical but easier to miss next time.\n\nOption (1) is symmetric with how `userCanViewServer` centralizes the server-visibility decision; the same pattern at the service layer would close this class once.",
  "id": "GHSA-vrmh-5mmx-hjwx",
  "modified": "2026-06-26T21:29:08Z",
  "published": "2026-06-10T13:39:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nezhahq/nezha/security/advisories/GHSA-vrmh-5mmx-hjwx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49397"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nezhahq/nezha"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Nezha\u0027s private services (`EnableShowInService: false`) are enumerable via per-server endpoints, leaking name and timing data"
}

GHSA-VRQ2-W7R7-3FP2

Vulnerability from github – Published: 2022-05-24 19:12 – Updated: 2025-11-07 23:21

Summary

Magento is affected by an improper authorization vulnerability

Details

Magento Commerce versions 2.4.2 (and earlier), 2.4.2-p1 (and earlier) and 2.3.7 (and earlier) are affected by an improper authorization vulnerability. An authenticated attacker could leverage this vulnerability to achieve sensitive information disclosure.

Severity

6.5 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/project-community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "versions": [
        "2.4.2"
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.2-p1"
            },
            {
              "fixed": "2.4.2-p2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "versions": [
        "2.3.7"
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.3.7-p1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-36037"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-11-07T23:21:19Z",
    "nvd_published_at": "2021-09-01T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Magento Commerce versions 2.4.2 (and earlier), 2.4.2-p1 (and earlier) and 2.3.7 (and earlier) are affected by an improper authorization vulnerability. An authenticated attacker could leverage this vulnerability to achieve sensitive information disclosure.",
  "id": "GHSA-vrq2-w7r7-3fp2",
  "modified": "2025-11-07T23:21:19Z",
  "published": "2022-05-24T19:12:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36037"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/magento/magento2"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/magento/apsb21-64.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Magento is affected by an improper authorization vulnerability"
}

GHSA-VRV5-28J8-RV7X

Vulnerability from github – Published: 2022-02-24 00:00 – Updated: 2022-03-03 00:01

Details

Improper Access Control in GitHub repository chocobozzz/peertube prior to 4.1.0.

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2022-0727"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-02-23T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Improper Access Control in GitHub repository chocobozzz/peertube prior to 4.1.0.",
  "id": "GHSA-vrv5-28j8-rv7x",
  "modified": "2022-03-03T00:01:03Z",
  "published": "2022-02-24T00:00:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0727"
    },
    {
      "type": "WEB",
      "url": "https://github.com/chocobozzz/peertube/commit/6ea9295b8f5dd7cc254202a79aad61c666cc4259"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/d1faa10f-0640-480c-bb52-089adb351e6e"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-VV27-WPRX-CXJ7

Vulnerability from github – Published: 2026-03-26 12:30 – Updated: 2026-03-26 12:30

Details

Vulnerability of incorrect authorization in HiJiffy Chatbot allows an attacker to download private messages from other users via the parameter 'visitor' in '/api/v1/webchat/message'.

Severity

6.9 (Medium)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-4263"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-26T10:16:26Z",
    "severity": "MODERATE"
  },
  "details": "Vulnerability of incorrect authorization in\u00a0HiJiffy Chatbot allows an attacker to download private messages from other users via the parameter\u00a0\n\u0027visitor\u0027 in \u0027/api/v1/webchat/message\u0027.",
  "id": "GHSA-vv27-wprx-cxj7",
  "modified": "2026-03-26T12:30:29Z",
  "published": "2026-03-26T12:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4263"
    },
    {
      "type": "WEB",
      "url": "https://www.incibe.es/en/incibe-cert/notices/aviso/multiple-vulnerabilities-hijiffy-chatbot"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-VV4W-HR59-HMW6

Vulnerability from github – Published: 2022-05-24 17:44 – Updated: 2024-04-04 03:04

Details

The auth_internal plugin in Tiny Tiny RSS (aka tt-rss) before 2021-03-12 allows an attacker to log in via the OTP code without a valid password. NOTE: this issue only affected the git master branch for a short time. However, all end users are explicitly directed to use the git master branch in production. Semantic version numbers such as 21.03 appear to exist, but are automatically generated from the year and month. They are not releases.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2021-28373"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-03-13T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "The auth_internal plugin in Tiny Tiny RSS (aka tt-rss) before 2021-03-12 allows an attacker to log in via the OTP code without a valid password. NOTE: this issue only affected the git master branch for a short time. However, all end users are explicitly directed to use the git master branch in production. Semantic version numbers such as 21.03 appear to exist, but are automatically generated from the year and month. They are not releases.",
  "id": "GHSA-vv4w-hr59-hmw6",
  "modified": "2024-04-04T03:04:53Z",
  "published": "2022-05-24T17:44:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28373"
    },
    {
      "type": "WEB",
      "url": "https://community.tt-rss.org/t/check-password-not-called-if-otp-is-enabled-update-asap-if-youre-using-2fa/4502"
    },
    {
      "type": "WEB",
      "url": "https://git.tt-rss.org/fox/tt-rss/commit/4949e1a59059d9e72ba7a98f783cec312c06c6d2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VV6F-F322-W3FX

Vulnerability from github – Published: 2022-05-24 17:29 – Updated: 2022-05-24 17:29

Details

A vulnerability in the CLI parser of Cisco IOS Software and Cisco IOS XE Software could allow an authenticated, local attacker to access files from the flash: filesystem. The vulnerability is due to insufficient application of restrictions during the execution of a specific command. An attacker could exploit this vulnerability by using a specific command at the command line. A successful exploit could allow the attacker to obtain read-only access to files that are located on the flash: filesystem that otherwise might not have been accessible.

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2020-3477"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-09-24T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in the CLI parser of Cisco IOS Software and Cisco IOS XE Software could allow an authenticated, local attacker to access files from the flash: filesystem. The vulnerability is due to insufficient application of restrictions during the execution of a specific command. An attacker could exploit this vulnerability by using a specific command at the command line. A successful exploit could allow the attacker to obtain read-only access to files that are located on the flash: filesystem that otherwise might not have been accessible.",
  "id": "GHSA-vv6f-f322-w3fx",
  "modified": "2022-05-24T17:29:28Z",
  "published": "2022-05-24T17:29:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-3477"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-info-disclosure-V4BmJBNF"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-VV73-F4GC-GGHX

Vulnerability from github – Published: 2025-06-10 18:32 – Updated: 2025-06-10 18:32

Details

A vulnerability has been identified in RUGGEDCOM RST2428P (6GK6242-6PA00) (All versions < V3.2), SCALANCE XC316-8 (6GK5324-8TS00-2AC2) (All versions < V3.2), SCALANCE XC324-4 (6GK5328-4TS00-2AC2) (All versions < V3.2), SCALANCE XC324-4 EEC (6GK5328-4TS00-2EC2) (All versions < V3.2), SCALANCE XC332 (6GK5332-0GA00-2AC2) (All versions < V3.2), SCALANCE XC416-8 (6GK5424-8TR00-2AC2) (All versions < V3.2), SCALANCE XC424-4 (6GK5428-4TR00-2AC2) (All versions < V3.2), SCALANCE XC432 (6GK5432-0GR00-2AC2) (All versions < V3.2), SCALANCE XCH328 (6GK5328-4TS01-2EC2) (All versions < V3.2), SCALANCE XCM324 (6GK5324-8TS01-2AC2) (All versions < V3.2), SCALANCE XCM328 (6GK5328-4TS01-2AC2) (All versions < V3.2), SCALANCE XCM332 (6GK5332-0GA01-2AC2) (All versions < V3.2), SCALANCE XR302-32 (6GK5334-5TS00-2AR3) (All versions < V3.2), SCALANCE XR302-32 (6GK5334-5TS00-3AR3) (All versions < V3.2), SCALANCE XR302-32 (6GK5334-5TS00-4AR3) (All versions < V3.2), SCALANCE XR322-12 (6GK5334-3TS00-2AR3) (All versions < V3.2), SCALANCE XR322-12 (6GK5334-3TS00-3AR3) (All versions < V3.2), SCALANCE XR322-12 (6GK5334-3TS00-4AR3) (All versions < V3.2), SCALANCE XR326-8 (6GK5334-2TS00-2AR3) (All versions < V3.2), SCALANCE XR326-8 (6GK5334-2TS00-3AR3) (All versions < V3.2), SCALANCE XR326-8 (6GK5334-2TS00-4AR3) (All versions < V3.2), SCALANCE XR326-8 EEC (6GK5334-2TS00-2ER3) (All versions < V3.2), SCALANCE XR502-32 (6GK5534-5TR00-2AR3) (All versions < V3.2), SCALANCE XR502-32 (6GK5534-5TR00-3AR3) (All versions < V3.2), SCALANCE XR502-32 (6GK5534-5TR00-4AR3) (All versions < V3.2), SCALANCE XR522-12 (6GK5534-3TR00-2AR3) (All versions < V3.2), SCALANCE XR522-12 (6GK5534-3TR00-3AR3) (All versions < V3.2), SCALANCE XR522-12 (6GK5534-3TR00-4AR3) (All versions < V3.2), SCALANCE XR526-8 (6GK5534-2TR00-2AR3) (All versions < V3.2), SCALANCE XR526-8 (6GK5534-2TR00-3AR3) (All versions < V3.2), SCALANCE XR526-8 (6GK5534-2TR00-4AR3) (All versions < V3.2), SCALANCE XRH334 (24 V DC, 8xFO, CC) (6GK5334-2TS01-2ER3) (All versions < V3.2), SCALANCE XRM334 (230 V AC, 12xFO) (6GK5334-3TS01-3AR3) (All versions < V3.2), SCALANCE XRM334 (230 V AC, 8xFO) (6GK5334-2TS01-3AR3) (All versions < V3.2), SCALANCE XRM334 (230V AC, 2x10G, 24xSFP, 8xSFP+) (6GK5334-5TS01-3AR3) (All versions < V3.2), SCALANCE XRM334 (24 V DC, 12xFO) (6GK5334-3TS01-2AR3) (All versions < V3.2), SCALANCE XRM334 (24 V DC, 8xFO) (6GK5334-2TS01-2AR3) (All versions < V3.2), SCALANCE XRM334 (24V DC, 2x10G, 24xSFP, 8xSFP+) (6GK5334-5TS01-2AR3) (All versions < V3.2), SCALANCE XRM334 (2x230 V AC, 12xFO) (6GK5334-3TS01-4AR3) (All versions < V3.2), SCALANCE XRM334 (2x230 V AC, 8xFO) (6GK5334-2TS01-4AR3) (All versions < V3.2), SCALANCE XRM334 (2x230V AC, 2x10G, 24xSFP, 8xSFP+) (6GK5334-5TS01-4AR3) (All versions < V3.2). An internal session termination functionality in the web interface of affected products contains an incorrect authorization check vulnerability. This could allow an authenticated remote attacker with "guest" role to terminate legitimate users' sessions.

Severity

4.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L

5.3 (Medium)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-40568"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-10T16:15:38Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability has been identified in RUGGEDCOM RST2428P (6GK6242-6PA00) (All versions \u003c V3.2), SCALANCE XC316-8 (6GK5324-8TS00-2AC2) (All versions \u003c V3.2), SCALANCE XC324-4 (6GK5328-4TS00-2AC2) (All versions \u003c V3.2), SCALANCE XC324-4 EEC (6GK5328-4TS00-2EC2) (All versions \u003c V3.2), SCALANCE XC332 (6GK5332-0GA00-2AC2) (All versions \u003c V3.2), SCALANCE XC416-8 (6GK5424-8TR00-2AC2) (All versions \u003c V3.2), SCALANCE XC424-4 (6GK5428-4TR00-2AC2) (All versions \u003c V3.2), SCALANCE XC432 (6GK5432-0GR00-2AC2) (All versions \u003c V3.2), SCALANCE XCH328 (6GK5328-4TS01-2EC2) (All versions \u003c V3.2), SCALANCE XCM324 (6GK5324-8TS01-2AC2) (All versions \u003c V3.2), SCALANCE XCM328 (6GK5328-4TS01-2AC2) (All versions \u003c V3.2), SCALANCE XCM332 (6GK5332-0GA01-2AC2) (All versions \u003c V3.2), SCALANCE XR302-32 (6GK5334-5TS00-2AR3) (All versions \u003c V3.2), SCALANCE XR302-32 (6GK5334-5TS00-3AR3) (All versions \u003c V3.2), SCALANCE XR302-32 (6GK5334-5TS00-4AR3) (All versions \u003c V3.2), SCALANCE XR322-12 (6GK5334-3TS00-2AR3) (All versions \u003c V3.2), SCALANCE XR322-12 (6GK5334-3TS00-3AR3) (All versions \u003c V3.2), SCALANCE XR322-12 (6GK5334-3TS00-4AR3) (All versions \u003c V3.2), SCALANCE XR326-8 (6GK5334-2TS00-2AR3) (All versions \u003c V3.2), SCALANCE XR326-8 (6GK5334-2TS00-3AR3) (All versions \u003c V3.2), SCALANCE XR326-8 (6GK5334-2TS00-4AR3) (All versions \u003c V3.2), SCALANCE XR326-8 EEC (6GK5334-2TS00-2ER3) (All versions \u003c V3.2), SCALANCE XR502-32 (6GK5534-5TR00-2AR3) (All versions \u003c V3.2), SCALANCE XR502-32 (6GK5534-5TR00-3AR3) (All versions \u003c V3.2), SCALANCE XR502-32 (6GK5534-5TR00-4AR3) (All versions \u003c V3.2), SCALANCE XR522-12 (6GK5534-3TR00-2AR3) (All versions \u003c V3.2), SCALANCE XR522-12 (6GK5534-3TR00-3AR3) (All versions \u003c V3.2), SCALANCE XR522-12 (6GK5534-3TR00-4AR3) (All versions \u003c V3.2), SCALANCE XR526-8 (6GK5534-2TR00-2AR3) (All versions \u003c V3.2), SCALANCE XR526-8 (6GK5534-2TR00-3AR3) (All versions \u003c V3.2), SCALANCE XR526-8 (6GK5534-2TR00-4AR3) (All versions \u003c V3.2), SCALANCE XRH334 (24 V DC, 8xFO, CC) (6GK5334-2TS01-2ER3) (All versions \u003c V3.2), SCALANCE XRM334 (230 V AC, 12xFO) (6GK5334-3TS01-3AR3) (All versions \u003c V3.2), SCALANCE XRM334 (230 V AC, 8xFO) (6GK5334-2TS01-3AR3) (All versions \u003c V3.2), SCALANCE XRM334 (230V AC, 2x10G, 24xSFP, 8xSFP+) (6GK5334-5TS01-3AR3) (All versions \u003c V3.2), SCALANCE XRM334 (24 V DC, 12xFO) (6GK5334-3TS01-2AR3) (All versions \u003c V3.2), SCALANCE XRM334 (24 V DC, 8xFO) (6GK5334-2TS01-2AR3) (All versions \u003c V3.2), SCALANCE XRM334 (24V DC, 2x10G, 24xSFP, 8xSFP+) (6GK5334-5TS01-2AR3) (All versions \u003c V3.2), SCALANCE XRM334 (2x230 V AC, 12xFO) (6GK5334-3TS01-4AR3) (All versions \u003c V3.2), SCALANCE XRM334 (2x230 V AC, 8xFO) (6GK5334-2TS01-4AR3) (All versions \u003c V3.2), SCALANCE XRM334 (2x230V AC, 2x10G, 24xSFP, 8xSFP+) (6GK5334-5TS01-4AR3) (All versions \u003c V3.2). An internal session termination functionality in the web interface of affected products contains an incorrect authorization check vulnerability. This could allow an authenticated remote attacker with \"guest\" role to terminate legitimate users\u0027 sessions.",
  "id": "GHSA-vv73-f4gc-gghx",
  "modified": "2025-06-10T18:32:25Z",
  "published": "2025-06-10T18:32:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40568"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-693776.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-VV89-HV6R-VGQH

Vulnerability from github – Published: 2026-07-29 12:31 – Updated: 2026-07-29 12:31

Details

Apache Traffic Server can bypass IP access controls on UDS listeners and through ACL matching errors.

This issue affects Apache Traffic Server: from 8.0.0 through 8.1.9, from 9.0.0 through 9.2.14, from 10.0.0 through 10.1.3.

Users are recommended to upgrade to version 9.2.15 or 10.1.4, which fix the issue.

Severity

8.2 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L

7.0 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-58159"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-29T10:16:41Z",
    "severity": "HIGH"
  },
  "details": "Apache Traffic Server can bypass IP access controls on UDS listeners and through ACL matching errors.\n\nThis issue affects Apache Traffic Server: from 8.0.0 through 8.1.9, from 9.0.0 through 9.2.14, from 10.0.0 through 10.1.3.\n\nUsers are recommended to upgrade to version 9.2.15 or 10.1.4, which fix the issue.",
  "id": "GHSA-vv89-hv6r-vgqh",
  "modified": "2026-07-29T12:31:21Z",
  "published": "2026-07-29T12:31:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-58159"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/5prl9glcm9g2swnq9hqxvnokylm1gr6d"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-VVG7-8RMQ-92G7

Vulnerability from github – Published: 2025-12-17 20:57 – Updated: 2025-12-17 20:57

Summary

Auth0 WordPress has Improper Audience Validation via Auth0-PHP SDK Dependency

Details

Description

In applications built with the Auth0-PHP SDK, the audience validation in access tokens is performed improperly. Without proper validation, affected applications may accept ID tokens as Access tokens.

Affected product and versions

Projects are affected if they meet the following preconditions:

Applications using the Auth0 Wordpress plugin with version between 5.0.0-BETA0 and 5.4.0,
Auth0 Wordpress plugin uses the Auth0-PHP SDK with versions between 8.0.0 and 8.17.0.

Resolution

Upgrade Auth0 Wordpress plugin to version 5.5.0 or greater.

Acknowledgement

Okta would like to thank Jafar Sadiq (iaf4r) for their discovery and responsible disclosure.

Severity

6.8 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.4.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "auth0/wordpress"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0-BETA0"
            },
            {
              "fixed": "5.5.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1395",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-17T20:57:09Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Description\nIn applications built with the Auth0-PHP SDK, the audience validation in access tokens is performed improperly. Without proper validation, affected applications may accept ID tokens as Access tokens.\n\n### Affected product and versions\nProjects are affected if they meet the following preconditions:\n\n- Applications using the Auth0 Wordpress plugin with version between 5.0.0-BETA0 and 5.4.0,\n- Auth0 Wordpress plugin uses the Auth0-PHP SDK with versions between 8.0.0 and 8.17.0.\n\n### Resolution\nUpgrade Auth0 Wordpress plugin to version 5.5.0 or greater.\n\n### Acknowledgement\nOkta would like to thank Jafar Sadiq (iaf4r) for their discovery and responsible disclosure.",
  "id": "GHSA-vvg7-8rmq-92g7",
  "modified": "2025-12-17T20:57:09Z",
  "published": "2025-12-17T20:57:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/auth0/wordpress/security/advisories/GHSA-vvg7-8rmq-92g7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/auth0/wordpress/commit/b207c6f7fd06507b90c4e6bcc18a857ef9e018de"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/auth0/wordpress"
    },
    {
      "type": "WEB",
      "url": "https://github.com/auth0/wordpress/releases/tag/5.5.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Auth0 WordPress has Improper Audience Validation via Auth0-PHP SDK Dependency"
}

CWE-863

Incorrect Authorization

GHSA-VRHC-JJFC-M3M3

Description

Root Cause

Proof of Concept

Impact

GHSA-VRMH-5MMX-HJWX

Private services (`EnableShowInService: false`) are enumerable via per-server endpoints, leaking name and timing data

Summary

Affected

Vulnerability details

[A] — single-source-of-truth filter exists at the listing site

[B] — `listServerServices` iterates `GetSortedList()` and emits hidden services

[C] — `getServiceHistory` returns the service name for any ID

The mismatch

Proof of concept

Impact

Direct

Indirect / second-order

Suggested fix

GHSA-VRQ2-W7R7-3FP2

GHSA-VRV5-28J8-RV7X

GHSA-VV27-WPRX-CXJ7

GHSA-VV4W-HR59-HMW6

GHSA-VV6F-F322-W3FX

GHSA-VV73-F4GC-GGHX

GHSA-VV89-HV6R-VGQH

GHSA-VVG7-8RMQ-92G7

Description

Affected product and versions

Resolution

Acknowledgement

Mitigation

Mitigation

Mitigation MIT-4.4

Mitigation

Mitigation

CWE-863

Incorrect Authorization

Description

Root Cause

Proof of Concept

Impact

Private services (EnableShowInService: false) are enumerable via per-server endpoints, leaking name and timing data

Summary

Affected

Vulnerability details

[A] — single-source-of-truth filter exists at the listing site

[B] — listServerServices iterates GetSortedList() and emits hidden services

[C] — getServiceHistory returns the service name for any ID

The mismatch

Proof of concept

Impact

Direct

Indirect / second-order

Suggested fix

Description

Affected product and versions

Resolution

Acknowledgement

Mitigation

Mitigation

Mitigation MIT-4.4

Mitigation

Mitigation

Private services (`EnableShowInService: false`) are enumerable via per-server endpoints, leaking name and timing data

[B] — `listServerServices` iterates `GetSortedList()` and emits hidden services

[C] — `getServiceHistory` returns the service name for any ID