GHSA-68RP-WP8R-4726

Vulnerability from github – Published: 2026-02-19 20:45 – Updated: 2026-02-23 22:28
VLAI
Summary
Flask session does not add `Vary: Cookie` header when accessed in some ways
Details

When the session object is accessed, Flask should set the Vary: Cookie header. This instructs caches not to cache the response, as it may contain information specific to a logged in user. This is handled in most cases, but some forms of access such as the Python in operator were overlooked.

The severity depends on the application's use of the session, and the cache's behavior regarding cookies. The risk depends on all these conditions being met.

  1. The application must be hosted behind a caching proxy that does not ignore responses with cookies.
  2. The application does not set a Cache-Control header to indicate that a page is private or should not be cached.
  3. The application accesses the session in a way that does not access the values, only the keys, and does not mutate the session.
Severity
2.3 (Low)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "flask"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-27205"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-524"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-19T20:45:41Z",
    "nvd_published_at": "2026-02-21T06:17:00Z",
    "severity": "LOW"
  },
  "details": "When the `session` object is accessed, Flask should set the `Vary: Cookie` header. This instructs caches not to cache the response, as it may contain information specific to a logged in user. This is handled in most cases, but some forms of access such as the Python `in` operator were overlooked.\n\nThe severity depends on the application\u0027s use of the session, and the cache\u0027s behavior regarding cookies. The risk depends on all these conditions being met.\n\n1. The application must be hosted behind a caching proxy that does not ignore responses with cookies.\n2. The application does not set a `Cache-Control` header to indicate that a page is private or should not be cached.\n3. The application accesses the session in a way that does not access the values, only the keys, and does not mutate the session.",
  "id": "GHSA-68rp-wp8r-4726",
  "modified": "2026-02-23T22:28:03Z",
  "published": "2026-02-19T20:45:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pallets/flask/security/advisories/GHSA-68rp-wp8r-4726"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27205"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pallets/flask/commit/089cb86dd22bff589a4eafb7ab8e42dc357623b4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pallets/flask"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pallets/flask/releases/tag/3.1.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Flask session does not add `Vary: Cookie` header when accessed in some ways"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.