CVE-2026-6790 (GCVE-0-2026-6790)
Vulnerability from cvelistv5
Published
2026-07-14 08:51
Modified
2026-07-14 12:20
Severity ?
5.3 (Medium) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
CWE
Summary
In Eclipse Jetty, for HTTP/1, HTTP/2 and HTTP/3 requests, there is no strict check that the request authority (host and port) matches what provided in the Host header (if present). This was not enforced in earlier HTTP RFC (for example, in RFC 2616), but it is in the latest RFC (9110 and 9112). This mismatch can cause a number of problems that may be classified as vulnerabilities such as: * URI constructions (for example, for redirects -- this is typical for login pages) * Virtual host selection * Reverse proxying * Misleading logs * Etc. Given that the latest RFCs require that request authority and Host header must match, Jetty should enforce this invariant.
References
Impacted products
Vendor Product Version
Eclipse Foundation Eclipse Jetty Version: 9.4.0   ≤ 9.4.60
Version: 10.0.0   ≤ 10.0.28
Version: 11.0.0   ≤ 11.0.28
Version: 12.0.0   ≤ 12.0.34
Version: 12.1.0   ≤ 12.1.8
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-6790",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-07-14T12:18:58.528202Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-07-14T12:20:35.130Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Eclipse Jetty",
          "repo": "https://github.com/jetty/jetty.project",
          "vendor": "Eclipse Foundation",
          "versions": [
            {
              "lessThanOrEqual": "9.4.60",
              "status": "affected",
              "version": "9.4.0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "10.0.28",
              "status": "affected",
              "version": "10.0.0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "11.0.28",
              "status": "affected",
              "version": "11.0.0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "12.0.34",
              "status": "affected",
              "version": "12.0.0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "12.1.8",
              "status": "affected",
              "version": "12.1.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eIn Eclipse Jetty, for HTTP/1, HTTP/2 and HTTP/3 requests, there is no strict check that the request authority (host and port) matches what provided in the \u003ccode\u003eHost\u003c/code\u003e header (if present).\u003c/p\u003e\n\u003cp\u003eThis was not enforced in earlier HTTP RFC (for example, in RFC 2616), but it is in the latest RFC (9110 and 9112).\u003c/p\u003e\n\u003cp\u003eThis mismatch can cause a number of problems that may be classified as vulnerabilities such as:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n        \n      URI constructions (for example, for redirects -- this is typical for login pages)\u003c/li\u003e\n\u003cli\u003e\n        \n      Virtual host selection\u003c/li\u003e\n\u003cli\u003e\n        \n      Reverse proxying\u003c/li\u003e\n\u003cli\u003e\n        \n      Misleading logs\u003c/li\u003e\n\u003cli\u003e\n        \n      Etc.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eGiven that the latest RFCs require that request authority and \u003ccode\u003eHost\u003c/code\u003e header must match, Jetty should enforce this invariant.\u003c/p\u003e"
            }
          ],
          "value": "In Eclipse Jetty, for HTTP/1, HTTP/2 and HTTP/3 requests, there is no strict check that the request authority (host and port) matches what provided in the Host header (if present).\n\n\n\n\nThis was not enforced in earlier HTTP RFC (for example, in RFC 2616), but it is in the latest RFC (9110 and 9112).\n\n\n\n\nThis mismatch can cause a number of problems that may be classified as vulnerabilities such as:\n\n\n\n  *  \n        \n      URI constructions (for example, for redirects -- this is typical for login pages)\n\n  *  \n        \n      Virtual host selection\n\n  *  \n        \n      Reverse proxying\n\n  *  \n        \n      Misleading logs\n\n  *  \n        \n      Etc.\n\n\n\n\n\n\nGiven that the latest RFCs require that request authority and Host header must match, Jetty should enforce this invariant."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 5.3,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "NONE",
            "integrityImpact": "LOW",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-20",
              "description": "CWE-20",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-07-14T08:51:30.527Z",
        "orgId": "e51fbebd-6053-4e49-959f-1b94eeb69a2c",
        "shortName": "eclipse"
      },
      "references": [
        {
          "url": "https://gitlab.eclipse.org/security/cve-assignment/-/work_items/99"
        }
      ],
      "x_generator": {
        "engine": "Vulnogram 1.0.2"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "e51fbebd-6053-4e49-959f-1b94eeb69a2c",
    "assignerShortName": "eclipse",
    "cveId": "CVE-2026-6790",
    "datePublished": "2026-07-14T08:51:30.527Z",
    "dateReserved": "2026-04-21T13:47:52.520Z",
    "dateUpdated": "2026-07-14T12:20:35.130Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2026-6790\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"yes\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2026-07-14T12:18:58.528202Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2026-07-14T12:20:30.586Z\"}}], \"cna\": {\"metrics\": [{\"format\": \"CVSS\", \"cvssV3_1\": {\"scope\": \"UNCHANGED\", \"version\": \"3.1\", \"baseScore\": 5.3, \"attackVector\": \"NETWORK\", \"baseSeverity\": \"MEDIUM\", \"vectorString\": \"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N\", \"integrityImpact\": \"LOW\", \"userInteraction\": \"NONE\", \"attackComplexity\": \"LOW\", \"availabilityImpact\": \"NONE\", \"privilegesRequired\": \"NONE\", \"confidentialityImpact\": \"NONE\"}, \"scenarios\": [{\"lang\": \"en\", \"value\": \"GENERAL\"}]}], \"affected\": [{\"repo\": \"https://github.com/jetty/jetty.project\", \"vendor\": \"Eclipse Foundation\", \"product\": \"Eclipse Jetty\", \"versions\": [{\"status\": \"affected\", \"version\": \"9.4.0\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"9.4.60\"}, {\"status\": \"affected\", \"version\": \"10.0.0\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"10.0.28\"}, {\"status\": \"affected\", \"version\": \"11.0.0\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"11.0.28\"}, {\"status\": \"affected\", \"version\": \"12.0.0\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"12.0.34\"}, {\"status\": \"affected\", \"version\": \"12.1.0\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"12.1.8\"}], \"defaultStatus\": \"unaffected\"}], \"references\": [{\"url\": \"https://gitlab.eclipse.org/security/cve-assignment/-/work_items/99\"}], \"x_generator\": {\"engine\": \"Vulnogram 1.0.2\"}, \"descriptions\": [{\"lang\": \"en\", \"value\": \"In Eclipse Jetty, for HTTP/1, HTTP/2 and HTTP/3 requests, there is no strict check that the request authority (host and port) matches what provided in the Host header (if present).\\n\\n\\n\\n\\nThis was not enforced in earlier HTTP RFC (for example, in RFC 2616), but it is in the latest RFC (9110 and 9112).\\n\\n\\n\\n\\nThis mismatch can cause a number of problems that may be classified as vulnerabilities such as:\\n\\n\\n\\n  *  \\n        \\n      URI constructions (for example, for redirects -- this is typical for login pages)\\n\\n  *  \\n        \\n      Virtual host selection\\n\\n  *  \\n        \\n      Reverse proxying\\n\\n  *  \\n        \\n      Misleading logs\\n\\n  *  \\n        \\n      Etc.\\n\\n\\n\\n\\n\\n\\nGiven that the latest RFCs require that request authority and Host header must match, Jetty should enforce this invariant.\", \"supportingMedia\": [{\"type\": \"text/html\", \"value\": \"\u003cp\u003eIn Eclipse Jetty, for HTTP/1, HTTP/2 and HTTP/3 requests, there is no strict check that the request authority (host and port) matches what provided in the \u003ccode\u003eHost\u003c/code\u003e header (if present).\u003c/p\u003e\\n\u003cp\u003eThis was not enforced in earlier HTTP RFC (for example, in RFC 2616), but it is in the latest RFC (9110 and 9112).\u003c/p\u003e\\n\u003cp\u003eThis mismatch can cause a number of problems that may be classified as vulnerabilities such as:\u003c/p\u003e\\n\u003cul\u003e\\n\u003cli\u003e\\n        \\n      URI constructions (for example, for redirects -- this is typical for login pages)\u003c/li\u003e\\n\u003cli\u003e\\n        \\n      Virtual host selection\u003c/li\u003e\\n\u003cli\u003e\\n        \\n      Reverse proxying\u003c/li\u003e\\n\u003cli\u003e\\n        \\n      Misleading logs\u003c/li\u003e\\n\u003cli\u003e\\n        \\n      Etc.\u003c/li\u003e\\n\u003c/ul\u003e\\n\u003cp\u003eGiven that the latest RFCs require that request authority and \u003ccode\u003eHost\u003c/code\u003e header must match, Jetty should enforce this invariant.\u003c/p\u003e\", \"base64\": false}]}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-20\", \"description\": \"CWE-20\"}]}], \"providerMetadata\": {\"orgId\": \"e51fbebd-6053-4e49-959f-1b94eeb69a2c\", \"shortName\": \"eclipse\", \"dateUpdated\": \"2026-07-14T08:51:30.527Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2026-6790\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-07-14T12:20:35.130Z\", \"dateReserved\": \"2026-04-21T13:47:52.520Z\", \"assignerOrgId\": \"e51fbebd-6053-4e49-959f-1b94eeb69a2c\", \"datePublished\": \"2026-07-14T08:51:30.527Z\", \"assignerShortName\": \"eclipse\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.