Common Weakness Enumeration
CWE-636
Allowed-with-ReviewNot Failing Securely ('Failing Open')
Abstraction: Class · Status: Draft
When the product encounters an error condition or failure, its design requires it to fall back to a state that is less secure than other options that are available, such as selecting the weakest encryption algorithm or using the most permissive access control restrictions.
79 vulnerabilities reference this CWE, most recent first.
CVE-2026-114479 (GCVE-0-2026-114479)
Vulnerability from cvelistv5 – Published: 2026-10-21 15:12 – Updated: 2026-10-21 17:19
VLAI
EPSS
VEX
Title
Not Failing Securely ('Failing Open') in hMailServer
Summary
Not failing securely in the anti-virus attachment-stripping action of Progressive Robot hMailServer 6.0.0 through 6.3.6 allows a remote unauthenticated attacker to have a message that the server's virus scanner found infected delivered to the recipient's mailbox unchanged. With virus scanning enabled and its action set to remove attachments and deliver the text (the default action deletes the message), the server keeps one text part of an infected message and replaces every attachment with a note. A message whose single part is not text - a program or an archive sent as the whole message, a message carried whole, a file declared an attachment, or an S/MIME message signed as one part, whose content the recipient's mail client opens - had no part the action could pick out, and was delivered as it arrived, with the content the scanner had found and nothing but a line in the application log to show it. Any sender can write such a message.
Severity
5.8 (Medium)
SSVC
Exploitation: none
Automatable: yes
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-21 15:37 UTC
CWE
- CWE-636 - Not Failing Securely ('Failing Open')
Assigner
GitLab
CNA
References
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Progressive Robot Ltd | hMailServer |
Affected:
6.0.0 , ≤ 6.3.6
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-114479",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-21T15:37:47.719617Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-21T17:19:12.258Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "hMailServer",
"repo": "https://gitlab.com/hmailserver/hmailserver",
"vendor": "Progressive Robot Ltd",
"versions": [
{
"lessThanOrEqual": "6.3.6",
"status": "affected",
"version": "6.0.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Found in the hMailServer project\u0027s own security review (Progressive Robot Ltd)"
}
],
"descriptions": [
{
"lang": "en",
"value": "Not failing securely in the anti-virus attachment-stripping action of Progressive Robot hMailServer 6.0.0 through 6.3.6 allows a remote unauthenticated attacker to have a message that the server\u0027s virus scanner found infected delivered to the recipient\u0027s mailbox unchanged. With virus scanning enabled and its action set to remove attachments and deliver the text (the default action deletes the message), the server keeps one text part of an infected message and replaces every attachment with a note. A message whose single part is not text - a program or an archive sent as the whole message, a message carried whole, a file declared an attachment, or an S/MIME message signed as one part, whose content the recipient\u0027s mail client opens - had no part the action could pick out, and was delivered as it arrived, with the content the scanner had found and nothing but a line in the application log to show it. Any sender can write such a message."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 5.8,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-636",
"description": "CWE-636: Not Failing Securely (\u0027Failing Open\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-21T15:12:50.851Z",
"orgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a",
"shortName": "GitLab"
},
"references": [
{
"url": "https://gitlab.com/hmailserver/hmailserver/-/work_items/92"
},
{
"url": "https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.7"
}
],
"solutions": [
{
"lang": "en",
"value": "Upgrade to hMailServer 6.3.7, in which the action replaces a message whose one part is an attachment, an S/MIME message signed as one part among them, with its note, as it replaces a message with no text part, and deletes a message it cannot read, or whose stripped form it cannot write over the message\u0027s file, as the delete action does, sending its recipients the message-deleted notice. A message that is one text part, and an encrypted message, are still delivered as they arrived. Until then, set the anti-virus action to delete the whole message, the default, wherever an infected message must not be delivered."
}
],
"title": "Not Failing Securely (\u0027Failing Open\u0027) in hMailServer"
}
},
"cveMetadata": {
"assignerOrgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a",
"assignerShortName": "GitLab",
"cveId": "CVE-2026-114479",
"datePublished": "2026-10-21T15:12:50.851Z",
"dateReserved": "2026-10-21T15:12:00.857Z",
"dateUpdated": "2026-10-21T17:19:12.258Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-110985 (GCVE-0-2026-110985)
Vulnerability from cvelistv5 – Published: 2026-10-28 16:37 – Updated: 2026-11-05 19:13
VLAI
EPSS
VEX
Title
Apache Kafka: Broker silently skips JWT signature verification for SASL/OAUTHBEARER when the JWKS endpoint URL is not configured
Summary
A Kafka broker using SASL/OAUTHBEARER with the default validator (sasl.oauthbearer.jwt.validator.class=DefaultJwtValidator) selects its implementation from configuration. When sasl.oauthbearer.jwks.endpoint.url is set, the validator verifies the JWT signature. When that URL is unset (the default) and no verification key resolver is supplied, DefaultJwtValidator silently falls back to ClientJwtValidator, which does not verify the JWT signature, algorithm, or issuer - and the broker starts with no warning or error. This is the residual of CVE-2026-33557, whose fix restored signature verification only on the path where the JWKS endpoint URL is set.
Impact:
A broker in this state accepts any structurally valid JWT, including "alg":"none" tokens. An unauthenticated remote attacker who can reach the listener can forge a token asserting any principal - including configured superusers - and gain full access to the cluster. Only brokers that enable SASL/OAUTHBEARER validation without a JWKS endpoint URL (and without a custom verification key resolver) are affected; brokers that set the URL verify signatures and are not affected. Unlike CVE-2026-110952 (issuer/audience not enforced by default), here no signature is verified at all.
Mitigation (all affected versions, no upgrade required):
Set sasl.oauthbearer.jwks.endpoint.url for every listener/mechanism that uses OAuthBearerValidatorCallbackHandler, or configure a signature-verifying sasl.oauthbearer.jwt.validator.class.
Resolution:
From Apache Kafka 4.2.2, 4.3.1, and 4.4.0: a broker that would fall back to the non-verifying ClientJwtValidator fails to start with a ConfigException instead of running without signature verification (secure by default).
Severity
9.1 (Critical)
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-11-05 19:13 UTC
CWE
Assigner
apache
CNA
References
1 reference
| URL | Tags |
|---|---|
| https://kafka.apache.org/cve-list | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Kafka |
Affected:
4.1.0 , ≤ 4.1.2
(semver)
Affected: 4.2.0 , ≤ 4.2.1 (semver) Affected: 4.3.0 (semver) |
{
"containers": {
"adp": [
{
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 9.1,
"baseSeverity": "CRITICAL",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"version": "3.1"
}
},
{
"other": {
"content": {
"id": "CVE-2026-110985",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-11-05T19:13:09.744748Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-11-05T19:13:23.510Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.kafka:kafka",
"packageURL": "pkg:maven/org.apache.kafka/kafka",
"product": "Apache Kafka",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThanOrEqual": "4.1.2",
"status": "affected",
"version": "4.1.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.2.1",
"status": "affected",
"version": "4.2.0",
"versionType": "semver"
},
{
"status": "affected",
"version": "4.3.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "San Zhang \u003cfalaxe1642@gmail.com\u003e"
},
{
"lang": "en",
"type": "reporter",
"value": "Kaixuan Li \u003ckaixuanli0131@gmail.com\u003e"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Evan Zhou \u003cezhou@confluent.io\u003e"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cdiv\u003eA Kafka broker using SASL/OAUTHBEARER with the default validator\u0026nbsp;\u003cspan\u003e(sasl.oauthbearer.jwt.validator.class=DefaultJwtValidator) selects its implementation from\u0026nbsp;\u003c/span\u003e\u003cspan\u003econfiguration. When sasl.oauthbearer.jwks.endpoint.url is set, the validator verifies the\u0026nbsp;\u003c/span\u003e\u003cspan\u003eJWT signature. When that URL is unset (the default) and no verification key resolver is\u0026nbsp;\u003c/span\u003e\u003cspan\u003esupplied, DefaultJwtValidator silently falls back to ClientJwtValidator, which does not\u0026nbsp;\u003c/span\u003e\u003cspan\u003everify the JWT signature, algorithm, or issuer - and the broker starts with no warning or\u0026nbsp;\u003c/span\u003e\u003cspan\u003eerror. This is the residual of CVE-2026-33557, whose fix restored signature verification\u0026nbsp;\u003c/span\u003e\u003cspan\u003eonly on the path where the JWKS endpoint URL is set.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eImpact:\u003c/div\u003e\u003cdiv\u003eA broker in this state accepts any structurally valid JWT, including \"alg\":\"none\" tokens. An\u0026nbsp;\u003cspan\u003eunauthenticated remote attacker who can reach the listener can forge a token asserting any\u0026nbsp;\u003c/span\u003e\u003cspan\u003eprincipal - including configured superusers - and gain full access to the cluster. Only\u0026nbsp;\u003c/span\u003e\u003cspan\u003ebrokers that enable SASL/OAUTHBEARER validation without a JWKS endpoint URL (and without a\u0026nbsp;\u003c/span\u003e\u003cspan\u003ecustom verification key resolver) are affected; brokers that set the URL verify signatures\u0026nbsp;\u003c/span\u003e\u003cspan\u003eand are not affected. Unlike CVE-2026-110952 (issuer/audience not enforced by default), here\u0026nbsp;\u003c/span\u003e\u003cspan\u003eno signature is verified at all.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eMitigation (all affected versions, no upgrade required):\u003c/div\u003e\u003cdiv\u003e\u003cdiv\u003eSet sasl.oauthbearer.jwks.endpoint.url for every listener/mechanism that uses\u0026nbsp;\u003cspan\u003eOAuthBearerValidatorCallbackHandler, or configure a signature-verifying\u0026nbsp;\u003c/span\u003e\u003cspan\u003esasl.oauthbearer.jwt.validator.class.\u003cbr\u003e\u003c/span\u003e\u003cspan\u003e\u003cbr\u003eResolution:\u003c/span\u003e\u003c/div\u003e\u003cdiv\u003e\u003cspan\u003eFrom Apache Kafka 4.2.2, 4.3.1, and 4.4.0: a broker that would fall back to the\u0026nbsp;\u003c/span\u003e\u003cspan\u003enon-verifying ClientJwtValidator fails to start with a ConfigException instead of running\u0026nbsp;\u003c/span\u003e\u003cspan\u003ewithout signature verification (secure by default).\u0026nbsp;\u003c/span\u003e\u003c/div\u003e\u003c/div\u003e"
}
],
"value": "A Kafka broker using SASL/OAUTHBEARER with the default validator\u00a0(sasl.oauthbearer.jwt.validator.class=DefaultJwtValidator) selects its implementation from\u00a0configuration. When sasl.oauthbearer.jwks.endpoint.url is set, the validator verifies the\u00a0JWT signature. When that URL is unset (the default) and no verification key resolver is\u00a0supplied, DefaultJwtValidator silently falls back to ClientJwtValidator, which does not\u00a0verify the JWT signature, algorithm, or issuer - and the broker starts with no warning or\u00a0error. This is the residual of CVE-2026-33557, whose fix restored signature verification\u00a0only on the path where the JWKS endpoint URL is set.\n\n\nImpact:\n\nA broker in this state accepts any structurally valid JWT, including \"alg\":\"none\" tokens. An\u00a0unauthenticated remote attacker who can reach the listener can forge a token asserting any\u00a0principal - including configured superusers - and gain full access to the cluster. Only\u00a0brokers that enable SASL/OAUTHBEARER validation without a JWKS endpoint URL (and without a\u00a0custom verification key resolver) are affected; brokers that set the URL verify signatures\u00a0and are not affected. Unlike CVE-2026-110952 (issuer/audience not enforced by default), here\u00a0no signature is verified at all.\n\n\nMitigation (all affected versions, no upgrade required):\n\nSet sasl.oauthbearer.jwks.endpoint.url for every listener/mechanism that uses\u00a0OAuthBearerValidatorCallbackHandler, or configure a signature-verifying\u00a0sasl.oauthbearer.jwt.validator.class.\n\nResolution:\n\nFrom Apache Kafka 4.2.2, 4.3.1, and 4.4.0: a broker that would fall back to the\u00a0non-verifying ClientJwtValidator fails to start with a ConfigException instead of running\u00a0without signature verification (secure by default)."
}
],
"metrics": [
{
"other": {
"content": {
"text": "important"
},
"type": "Textual description of severity"
},
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-345",
"description": "CWE-345 Insufficient Verification of Data Authenticity and its child",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-347",
"description": "CWE-347 Improper verification of cryptographic signature",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-1287",
"description": "CWE-1287 Improper validation of specified type of input",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-636",
"description": "CWE-636 Failing Open",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-28T16:37:45.688Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://kafka.apache.org/cve-list"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Apache Kafka: Broker silently skips JWT signature verification for SASL/OAUTHBEARER when the JWKS endpoint URL is not configured",
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-110985",
"datePublished": "2026-10-28T16:37:45.688Z",
"dateReserved": "2026-10-15T11:31:31.708Z",
"dateUpdated": "2026-11-05T19:13:23.510Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-109593 (GCVE-0-2026-109593)
Vulnerability from cvelistv5 – Published: 2026-11-03 16:25 – Updated: 2026-11-03 17:06 Unsupported When Assigned
VLAI
EPSS
VEX
Summary
An unauthenticated attacker with network access to the SonicWall GMS 9.5.2 and earlier versions may be able to read internal GMS files, potentially exposing sensitive information.
Severity
9.1 (Critical)
SSVC
Exploitation: none
Automatable: yes
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-11-03 17:06 UTC
CWE
- CWE-636 - Not Failing Securely
Assigner
sonicwall
CNA
References
1 reference
| URL | Tags |
|---|---|
| https://psirt.global.sonicwall.com/vuln-detail/SN… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| SonicWall | Global Management System (GMS) |
Affected:
9.5.2 and earlier versions
|
Date Public
2026-11-03 16:11
{
"containers": {
"adp": [
{
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 9.1,
"baseSeverity": "CRITICAL",
"confidentialityImpact": "HIGH",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
"version": "3.1"
}
},
{
"other": {
"content": {
"id": "CVE-2026-109593",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-11-03T17:06:10.311409Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-11-03T17:06:12.837Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unknown",
"platforms": [
"Windows",
"Linux"
],
"product": "Global Management System (GMS)",
"vendor": "SonicWall",
"versions": [
{
"status": "affected",
"version": "9.5.2 and earlier versions"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Matei \u0027Mal\u0027 Badanoiu of Pentest-Tools.com"
}
],
"datePublic": "2026-11-03T16:11:00.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "An unauthenticated attacker with network access to the SonicWall GMS 9.5.2 and earlier versions may be able to read internal GMS files, potentially exposing sensitive information."
}
],
"value": "An unauthenticated attacker with network access to the SonicWall GMS 9.5.2 and earlier versions may be able to read internal GMS files, potentially exposing sensitive information."
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-636",
"description": "CWE-636 Not Failing Securely",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-11-03T16:25:11.831Z",
"orgId": "44b2ff79-1416-4492-88bb-ed0da00c7315",
"shortName": "sonicwall"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2026-0019"
}
],
"source": {
"advisory": "SNWLID-2026-0019",
"discovery": "EXTERNAL"
},
"tags": [
"unsupported-when-assigned"
],
"x_generator": {
"engine": "Vulnogram 1.0.5"
}
}
},
"cveMetadata": {
"assignerOrgId": "44b2ff79-1416-4492-88bb-ed0da00c7315",
"assignerShortName": "sonicwall",
"cveId": "CVE-2026-109593",
"datePublished": "2026-11-03T16:25:11.831Z",
"dateReserved": "2026-10-12T20:55:18.449Z",
"dateUpdated": "2026-11-03T17:06:12.837Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-109408 (GCVE-0-2026-109408)
Vulnerability from cvelistv5 – Published: 2026-11-05 07:36 – Updated: 2026-11-05 19:05
VLAI
EPSS
VEX
Title
vault-java-driver: SslConfig silently disables requested TLS verification
Summary
vault-java-driver, a Java client for HashiCorp Vault, silently disables TLS certificate and hostname verification in three states where the caller asked for verification: an SslConfig passed to VaultConfig without calling build(), an SslConfig restored by Java deserialization, and VAULT_SSL_VERIFY set to a truthy value other than "true", such as 1, yes or on. In each case SslConfig.isVerify() returns false and the driver installs a trust-all SSLContext. An attacker on the network path to the Vault server can then read the Vault token and secrets in transit and forge responses. This issue affects io.github.jopenlibs:vault-java-driver 5.2.0 through 6.2.3. It is fixed in 7.0.0.
Severity
7.4 (High)
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-11-05 16:40 UTC
CWE
Assigner
Echo
CNA
References
2 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| jopenlibs | vault-java-driver |
Affected:
5.2.0 , < 7.0.0
(maven)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-109408",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-11-05T16:40:51.548101Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-11-05T19:05:53.450Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "io.github.jopenlibs:vault-java-driver",
"product": "vault-java-driver",
"programFiles": [
"src/main/java/io/github/jopenlibs/vault/SslConfig.java",
"src/main/java/io/github/jopenlibs/vault/rest/Rest.java"
],
"repo": "https://github.com/jopenlibs/vault-java-driver",
"vendor": "jopenlibs",
"versions": [
{
"lessThan": "7.0.0",
"status": "affected",
"version": "5.2.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Yuval Saggie and Mor Wienberger (powered by Echo Frontier)"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003evault-java-driver, a Java client for HashiCorp Vault, silently disables TLS certificate and hostname verification in three states where the caller asked for verification: an SslConfig passed to VaultConfig without calling build(), an SslConfig restored by Java deserialization, and VAULT_SSL_VERIFY set to a truthy value other than \"true\", such as 1, yes or on. In each case SslConfig.isVerify() returns false and the driver installs a trust-all SSLContext. An attacker on the network path to the Vault server can then read the Vault token and secrets in transit and forge responses. This issue affects io.github.jopenlibs:vault-java-driver 5.2.0 through 6.2.3. It is fixed in 7.0.0.\u003c/p\u003e"
}
],
"value": "vault-java-driver, a Java client for HashiCorp Vault, silently disables TLS certificate and hostname verification in three states where the caller asked for verification: an SslConfig passed to VaultConfig without calling build(), an SslConfig restored by Java deserialization, and VAULT_SSL_VERIFY set to a truthy value other than \"true\", such as 1, yes or on. In each case SslConfig.isVerify() returns false and the driver installs a trust-all SSLContext. An attacker on the network path to the Vault server can then read the Vault token and secrets in transit and forge responses. This issue affects io.github.jopenlibs:vault-java-driver 5.2.0 through 6.2.3. It is fixed in 7.0.0."
}
],
"impacts": [
{
"capecId": "CAPEC-94",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-94 Adversary in the Middle (AiTM)"
}
]
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 7.4,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-636",
"description": "CWE-636 Not Failing Securely (\u0027Failing Open\u0027)",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-295",
"description": "CWE-295 Improper Certificate Validation",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-297",
"description": "CWE-297 Improper Validation of Certificate with Host Mismatch",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-11-05T07:36:07.410Z",
"orgId": "abd028dc-c042-4c4d-9749-38d0f850af89",
"shortName": "Echo"
},
"references": [
{
"tags": [
"patch"
],
"url": "https://github.com/jopenlibs/vault-java-driver/pull/78"
},
{
"tags": [
"patch"
],
"url": "https://repo.maven.apache.org/maven2/io/github/jopenlibs/vault-java-driver/7.0.0/"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade io.github.jopenlibs:vault-java-driver to 7.0.0 or later.\u003cbr\u003e\u003c/p\u003e"
}
],
"value": "Upgrade io.github.jopenlibs:vault-java-driver to 7.0.0 or later."
}
],
"source": {
"discovery": "EXTERNAL"
},
"timeline": [
{
"lang": "en",
"time": "2026-10-05T14:00:00.000Z",
"value": "Reported to the maintainers"
},
{
"lang": "en",
"time": "2026-10-08T14:00:00.000Z",
"value": "Fix published as pull request #78"
}
],
"title": "vault-java-driver: SslConfig silently disables requested TLS verification",
"x_generator": {
"engine": "Vulnogram 1.0.5"
}
}
},
"cveMetadata": {
"assignerOrgId": "abd028dc-c042-4c4d-9749-38d0f850af89",
"assignerShortName": "Echo",
"cveId": "CVE-2026-109408",
"datePublished": "2026-11-05T07:36:07.410Z",
"dateReserved": "2026-10-12T14:55:10.201Z",
"dateUpdated": "2026-11-05T19:05:53.450Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-108142 (GCVE-0-2026-108142)
Vulnerability from cvelistv5 – Published: 2026-10-27 16:16 – Updated: 2026-11-04 20:24
VLAI
EPSS
VEX
Summary
A vulnerability allowing an unauthenticated attacker to bypass authorization on the CDP Coordinator Service.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-11-04 19:32 UTC
CWE
- CWE-636 - Not Failing Securely ('Failing Open')
Assigner
hackerone
CNA
References
1 reference
| URL | Tags |
|---|---|
| https://www.veeam.com/kb4948 |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Veeam | Backup and Replication |
Affected:
13.0 , < 13.0.3
(semver)
Affected: 13.1 , < 13.1.2 (semver) |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-108142",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-11-04T19:32:13.522690Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-11-04T20:24:27.620Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Backup and Replication",
"vendor": "Veeam",
"versions": [
{
"lessThan": "13.0.3",
"status": "affected",
"version": "13.0",
"versionType": "semver"
},
{
"lessThan": "13.1.2",
"status": "affected",
"version": "13.1",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "A vulnerability allowing an unauthenticated attacker to bypass authorization on the CDP Coordinator Service."
}
],
"metrics": [
{
"cvssV4_0": {
"baseScore": 9.1,
"baseSeverity": "CRITICAL",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:H",
"version": "4.0"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-636",
"description": "CWE-636 Not Failing Securely (\u0027Failing Open\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-27T16:16:58.907Z",
"orgId": "36234546-b8fa-4601-9d6f-f4e334aa8ea1",
"shortName": "hackerone"
},
"references": [
{
"url": "https://www.veeam.com/kb4948"
}
]
}
},
"cveMetadata": {
"assignerOrgId": "36234546-b8fa-4601-9d6f-f4e334aa8ea1",
"assignerShortName": "hackerone",
"cveId": "CVE-2026-108142",
"datePublished": "2026-10-27T16:16:58.907Z",
"dateReserved": "2026-10-09T15:00:00.772Z",
"dateUpdated": "2026-11-04T20:24:27.620Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-107735 (GCVE-0-2026-107735)
Vulnerability from cvelistv5 – Published: 2026-10-08 22:26 – Updated: 2026-10-09 15:24
VLAI
EPSS
VEX
Title
SumatraPDF: `sumatrapdfrestrict.ini` never revokes any permission (fail-open policy initialization)
Summary
SumatraPDF is a multi-format reader for Windows. In 3.6.1 and earlier, InitializePolicies() starts the sumatrapdfrestrict.ini path with gPolicyRestrictions set to Perm::All and only ORs permission bits, so the INI file never revokes permissions. Deploying SumatraPDF with this INI file, including a malformed file or zero-valued permission settings, can silently bypass configured disk, network, printing, registry, clipboard, preference, and fullscreen restrictions. The -restrict command-line path works correctly and is not affected. No fixed version is available as of this review.
Severity
SSVC
Exploitation: poc
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-09 15:23 UTC
CWE
- CWE-636 - Not Failing Securely ('Failing Open')
Assigner
GitHub_M
CNA
References
2 references
| URL | Tags |
|---|---|
| https://github.com/sumatrapdfreader/sumatrapdf/se… | x_refsource_CONFIRM |
| https://github.com/sumatrapdfreader/sumatrapdf/co… | x_refsource_MISC |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| sumatrapdfreader | sumatrapdf |
Affected:
<= 3.6.1
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-107735",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-09T15:23:33.802851Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-09T15:24:14.433Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/sumatrapdfreader/sumatrapdf/security/advisories/GHSA-crhm-w5qr-wjj4"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "sumatrapdf",
"vendor": "sumatrapdfreader",
"versions": [
{
"status": "affected",
"version": "\u003c= 3.6.1"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "SumatraPDF is a multi-format reader for Windows. In 3.6.1 and earlier, InitializePolicies() starts the sumatrapdfrestrict.ini path with gPolicyRestrictions set to Perm::All and only ORs permission bits, so the INI file never revokes permissions. Deploying SumatraPDF with this INI file, including a malformed file or zero-valued permission settings, can silently bypass configured disk, network, printing, registry, clipboard, preference, and fullscreen restrictions. The -restrict command-line path works correctly and is not affected. No fixed version is available as of this review."
}
],
"metrics": [
{
"cvssV4_0": {
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "LOCAL",
"baseScore": 5.4,
"baseSeverity": "MEDIUM",
"privilegesRequired": "LOW",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "PASSIVE",
"vectorString": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-636",
"description": "CWE-636: Not Failing Securely (\u0027Failing Open\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-08T22:26:00.405Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/sumatrapdfreader/sumatrapdf/security/advisories/GHSA-crhm-w5qr-wjj4",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/sumatrapdfreader/sumatrapdf/security/advisories/GHSA-crhm-w5qr-wjj4"
},
{
"name": "https://github.com/sumatrapdfreader/sumatrapdf/commit/f72948b59405d3ddba527789898050ef411d0bb8",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/sumatrapdfreader/sumatrapdf/commit/f72948b59405d3ddba527789898050ef411d0bb8"
}
],
"source": {
"advisory": "GHSA-crhm-w5qr-wjj4",
"discovery": "UNKNOWN"
},
"title": "SumatraPDF: `sumatrapdfrestrict.ini` never revokes any permission (fail-open policy initialization)"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-107735",
"datePublished": "2026-10-08T22:26:00.405Z",
"dateReserved": "2026-10-08T17:21:52.977Z",
"dateUpdated": "2026-10-09T15:24:14.433Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-107584 (GCVE-0-2026-107584)
Vulnerability from cvelistv5 – Published: 2026-10-08 11:49 – Updated: 2026-10-08 17:34
VLAI
EPSS
VEX
Title
Not Failing Securely ('Failing Open') in hMailServer
Summary
Progressive Robot hMailServer 6.0.0 through 6.3.5 fails open when applying DANE (RFC 7672) to outbound SMTP delivery. The server's validating DNSSEC resolver treated a TLSA or MX lookup that did not complete (no answer, SERVFAIL, a malformed reply), an answer without the requested records and without an NSEC/NSEC3 proof of their absence, and an answer whose records carried no applicable RRSIG as if the recipient domain were unsigned, and from 6.2.19 it also delivered to mail exchangers taken from an unvalidated MX lookup that the DNSSEC-validated MX record set did not name. An attacker who can drop, forge or strip DNS answers on the path to the server's resolver, at the resolver, or between the resolver and the recipient domain's name servers, and who holds an active position on the SMTP path, can thereby disable DANE for a DNSSEC-signed recipient domain and cause messages to be delivered in cleartext or to a host of the attacker's choosing with an arbitrary certificate, where they can be read and modified.
Severity
7.4 (High)
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-08 17:34 UTC
CWE
- CWE-636 - Not Failing Securely ('Failing Open')
Assigner
GitLab
CNA
References
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Progressive Robot Ltd | hMailServer |
Affected:
6.0.0 , < 6.3.6
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-107584",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-08T17:34:29.771696Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-08T17:34:40.561Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "hMailServer",
"repo": "https://gitlab.com/hmailserver/hmailserver",
"vendor": "Progressive Robot Ltd",
"versions": [
{
"lessThan": "6.3.6",
"status": "affected",
"version": "6.0.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Found in the hMailServer project\u0027s own security review (Progressive Robot Ltd)"
}
],
"descriptions": [
{
"lang": "en",
"value": "Progressive Robot hMailServer 6.0.0 through 6.3.5 fails open when applying DANE (RFC 7672) to outbound SMTP delivery. The server\u0027s validating DNSSEC resolver treated a TLSA or MX lookup that did not complete (no answer, SERVFAIL, a malformed reply), an answer without the requested records and without an NSEC/NSEC3 proof of their absence, and an answer whose records carried no applicable RRSIG as if the recipient domain were unsigned, and from 6.2.19 it also delivered to mail exchangers taken from an unvalidated MX lookup that the DNSSEC-validated MX record set did not name. An attacker who can drop, forge or strip DNS answers on the path to the server\u0027s resolver, at the resolver, or between the resolver and the recipient domain\u0027s name servers, and who holds an active position on the SMTP path, can thereby disable DANE for a DNSSEC-signed recipient domain and cause messages to be delivered in cleartext or to a host of the attacker\u0027s choosing with an arbitrary certificate, where they can be read and modified."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 7.4,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-636",
"description": "CWE-636: Not Failing Securely (\u0027Failing Open\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-08T11:49:16.083Z",
"orgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a",
"shortName": "GitLab"
},
"references": [
{
"url": "https://gitlab.com/hmailserver/hmailserver/-/work_items/64"
},
{
"url": "https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.6"
}
],
"solutions": [
{
"lang": "en",
"value": "Upgrade to hMailServer 6.3.6, which treats an incomplete, unsigned or unproven DNSSEC answer for a TLSA or MX lookup under a signed zone as indeterminate, does not use a mail exchanger whose lookup was indeterminate, defers the delivery when none is left, delivers only to mail exchangers named by a DNSSEC-validated MX record set, and (for a host whose DNS servers are IPv6 only) asks those IPv6 servers. Until then, for each recipient domain whose mail must be protected, an SMTP route that names its mail exchangers with the connection security \u0027STARTTLS (required)\u0027, with remote certificate verification on (VerifyRemoteSslCertificate=1), prevents delivery in cleartext or to another host for that domain; and the server\u0027s DNS resolver should be one reached over a trusted path, such as a validating resolver on the same host."
}
],
"title": "Not Failing Securely (\u0027Failing Open\u0027) in hMailServer"
}
},
"cveMetadata": {
"assignerOrgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a",
"assignerShortName": "GitLab",
"cveId": "CVE-2026-107584",
"datePublished": "2026-10-08T11:49:16.083Z",
"dateReserved": "2026-10-08T10:52:25.635Z",
"dateUpdated": "2026-10-08T17:34:40.561Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-107314 (GCVE-0-2026-107314)
Vulnerability from cvelistv5 – Published: 2026-10-07 23:03 – Updated: 2026-10-08 14:47
VLAI
EPSS
VEX
Title
pgjdbc does not enforce requireAuth when the value excludes every authentication method
Summary
pgjdbc, the PostgreSQL JDBC Driver, versions 42.7.11 through 42.7.13 enforce no restriction when the requireAuth connection property excludes all six authentication methods the driver knows, for example requireAuth=!password,!md5,!gss,!sspi,!scram-sha-256,!none. The driver then accepts any method the server asks for, including cleartext password authentication. A value without a method in it, such as requireAuth=, (a single comma), is affected the same way. An attacker positioned between the application and its server can ask for cleartext password authentication and receive the database password. A positive list such as requireAuth=scram-sha-256, and a partial exclusion such as requireAuth=!password,!md5, are enforced correctly. The property has no default value, so a deployment that does not set it is not affected. 42.7.14 fixes the problem: such a connection is refused with SQLState 08004, and a value without a method in it is rejected as invalid.
Severity
5.9 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-08 14:45 UTC
CWE
- CWE-636 - Not Failing Securely ('Failing Open')
Assigner
PostgreSQL
CNA
References
1 reference
| URL | Tags |
|---|---|
| https://github.com/pgjdbc/pgjdbc/security/advisor… | vendor-advisory |
Impacted products
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-107314",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-08T14:45:17.563568Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-08T14:47:31.949Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.postgresql:postgresql",
"product": "pgjdbc",
"programFiles": [
"pgjdbc/src/main/java/org/postgresql/core/AuthMethod.java"
],
"programRoutines": [
{
"name": "org.postgresql.core.AuthMethod.parseRequireAuth"
},
{
"name": "org.postgresql.core.AuthMethod.checkAuth"
}
],
"repo": "https://github.com/pgjdbc/pgjdbc",
"vendor": "pgjdbc",
"versions": [
{
"lessThan": "42.7.14",
"status": "affected",
"version": "42.7.11",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Daniel Coles"
}
],
"descriptions": [
{
"lang": "en",
"value": "pgjdbc, the PostgreSQL JDBC Driver, versions 42.7.11 through 42.7.13 enforce no restriction when the requireAuth connection property excludes all six authentication methods the driver knows, for example requireAuth=!password,!md5,!gss,!sspi,!scram-sha-256,!none. The driver then accepts any method the server asks for, including cleartext password authentication. A value without a method in it, such as requireAuth=, (a single comma), is affected the same way. An attacker positioned between the application and its server can ask for cleartext password authentication and receive the database password. A positive list such as requireAuth=scram-sha-256, and a partial exclusion such as requireAuth=!password,!md5, are enforced correctly. The property has no default value, so a deployment that does not set it is not affected. 42.7.14 fixes the problem: such a connection is refused with SQLState 08004, and a value without a method in it is rejected as invalid."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 5.9,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "HIGH",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-636",
"description": "CWE-636 Not Failing Securely (\u0027Failing Open\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-07T23:03:01.500Z",
"orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
"shortName": "PostgreSQL"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://github.com/pgjdbc/pgjdbc/security/advisories/GHSA-rhp9-mr79-r74h"
}
],
"solutions": [
{
"lang": "en",
"value": "Upgrade to pgjdbc 42.7.14 or later, and replace a requireAuth value that excludes every method or names none with a positive list of the methods the server uses."
}
],
"title": "pgjdbc does not enforce requireAuth when the value excludes every authentication method",
"workarounds": [
{
"lang": "en",
"value": "Replace the requireAuth value with a positive list of the methods the server uses, for example requireAuth=scram-sha-256; a positive list is enforced correctly on every affected version. A deployment that uses SCRAM over TLS can also set channelBinding=require, which refuses every authentication request other than SCRAM. Verifying the server certificate with sslmode=verify-full against a trusted CA prevents an attacker from presenting a substitute server."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
"assignerShortName": "PostgreSQL",
"cveId": "CVE-2026-107314",
"datePublished": "2026-10-07T23:03:01.500Z",
"dateReserved": "2026-10-07T16:53:39.434Z",
"dateUpdated": "2026-10-08T14:47:31.949Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-105933 (GCVE-0-2026-105933)
Vulnerability from cvelistv5 – Published: 2026-10-21 18:07 – Updated: 2026-10-23 22:00
VLAI
EPSS
VEX
Title
Apache Pulsar: Namespace encryption requirement not enforced after a failure during topic initialization
Summary
Apache Pulsar allows an administrator to require end-to-end message encryption for all topics in a namespace by setting the encryption_required namespace policy. When this policy is set, the broker rejects messages that are published without encryption.
When the broker loads a persistent topic, it reads the namespace policies and the topic-level policies as part of topic initialization. If a step of this initialization fails, for example because of an error reading from the metadata store, a failure loading the topic-level policies or a failure in a later initialization step, the broker logs a warning, disables the encryption requirement for that topic, and completes the topic load as if it had succeeded. The topic is then served with encryption_required not enforced, even though the namespace policy requires it. Topic-level policies that could not be loaded are also not applied.
While the encryption requirement is not enforced, an authenticated client with permission to produce to the affected topic can publish messages that are not encrypted, and the broker accepts and stores them. This applies both to producers created after the topic was loaded and to producers that were already connected. Messages published with encryption remain encrypted; the issue does not expose the content of encrypted messages or the encryption keys.
The condition is not limited to transient failures. If the cause of the initialization failure persists, the encryption requirement is disabled again each time the topic is loaded, for example after a topic unload, a namespace bundle reassignment or a broker restart. An update to the namespace policies restores enforcement on a loaded topic, but only until the topic is loaded again. Enforcement is reliably restored only once the underlying cause of the failure has been resolved and the topic has been loaded again. The broker logs a warning when the encryption requirement is disabled, but the topic load is reported as successful and the state of the encryption requirement is not shown in the topic statistics.
In fixed versions, a failure during topic initialization causes the topic load to fail so that it can be retried, instead of loading the topic with the encryption requirement disabled.
This issue affects Apache Pulsar versions from 1.22.0-incubating before 4.0.14 and from 4.1.0 before 4.2.5.
- 4.0.x version users should upgrade to at least 4.0.14.
- 4.1.x and 4.2.x version users should upgrade to at least 4.2.5.
Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions.
The currently supported Apache Pulsar release lines are 4.0.x and 5.0.x. The supported versions schedule is available at https://pulsar.apache.org/contribute/release-policy/.
Users who rely on encryption_required and cannot upgrade immediately can monitor the broker logs for warnings containing "isEncryptionRequired will be set to false" (the exact wording of the message differs between releases), resolve the underlying cause of the failure, and then reload the affected topic and confirm that the warning does not recur.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-23 20:42 UTC
CWE
- CWE-636 - Not Failing Securely ('Failing Open')
Assigner
apache
CNA
References
2 references
| URL | Tags |
|---|---|
| https://pulsar.apache.org/security/CVE-2026-105933/ | vendor-advisory |
| https://lists.apache.org/thread.html/f9xdlh72zf7g… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Pulsar |
Affected:
1.22.0-incubating , < 4.0.14
(semver)
Affected: 4.1.0 , < 4.2.5 (semver) |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-105933",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-23T20:42:27.441239Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-23T22:00:14.676Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Pulsar",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.0.14",
"status": "affected",
"version": "1.22.0-incubating",
"versionType": "semver"
},
{
"lessThan": "4.2.5",
"status": "affected",
"version": "4.1.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Sepuri Sai Krishna"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "Apache Pulsar allows an administrator to require end-to-end message encryption for all topics in a namespace by setting the encryption_required namespace policy. When this policy is set, the broker rejects messages that are published without encryption.\u003cbr\u003e\u003cbr\u003eWhen the broker loads a persistent topic, it reads the namespace policies and the topic-level policies as part of topic initialization. If a step of this initialization fails, for example because of an error reading from the metadata store, a failure loading the topic-level policies or a failure in a later initialization step, the broker logs a warning, disables the encryption requirement for that topic, and completes the topic load as if it had succeeded. The topic is then served with encryption_required not enforced, even though the namespace policy requires it. Topic-level policies that could not be loaded are also not applied.\u003cbr\u003e\u003cbr\u003eWhile the encryption requirement is not enforced, an authenticated client with permission to produce to the affected topic can publish messages that are not encrypted, and the broker accepts and stores them. This applies both to producers created after the topic was loaded and to producers that were already connected. Messages published with encryption remain encrypted; the issue does not expose the content of encrypted messages or the encryption keys.\u003cbr\u003e\u003cbr\u003eThe condition is not limited to transient failures. If the cause of the initialization failure persists, the encryption requirement is disabled again each time the topic is loaded, for example after a topic unload, a namespace bundle reassignment or a broker restart. An update to the namespace policies restores enforcement on a loaded topic, but only until the topic is loaded again. Enforcement is reliably restored only once the underlying cause of the failure has been resolved and the topic has been loaded again. The broker logs a warning when the encryption requirement is disabled, but the topic load is reported as successful and the state of the encryption requirement is not shown in the topic statistics.\u003cbr\u003e\u003cbr\u003eIn fixed versions, a failure during topic initialization causes the topic load to fail so that it can be retried, instead of loading the topic with the encryption requirement disabled.\u003cbr\u003e\u003cbr\u003eThis issue affects Apache Pulsar versions from 1.22.0-incubating before 4.0.14 and from 4.1.0 before 4.2.5.\u003cbr\u003e\u003cbr\u003e- 4.0.x version users should upgrade to at least 4.0.14.\u003cbr\u003e- 4.1.x and 4.2.x version users should upgrade to at least 4.2.5.\u003cbr\u003e\u003cbr\u003eUsers operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions.\u003cbr\u003e\u003cbr\u003eThe currently supported Apache Pulsar release lines are 4.0.x and 5.0.x. The supported versions schedule is available at https://pulsar.apache.org/contribute/release-policy/.\u003cbr\u003e\u003cbr\u003eUsers who rely on encryption_required and cannot upgrade immediately can monitor the broker logs for warnings containing \"isEncryptionRequired will be set to false\" (the exact wording of the message differs between releases), resolve the underlying cause of the failure, and then reload the affected topic and confirm that the warning does not recur."
}
],
"value": "Apache Pulsar allows an administrator to require end-to-end message encryption for all topics in a namespace by setting the encryption_required namespace policy. When this policy is set, the broker rejects messages that are published without encryption.\n\nWhen the broker loads a persistent topic, it reads the namespace policies and the topic-level policies as part of topic initialization. If a step of this initialization fails, for example because of an error reading from the metadata store, a failure loading the topic-level policies or a failure in a later initialization step, the broker logs a warning, disables the encryption requirement for that topic, and completes the topic load as if it had succeeded. The topic is then served with encryption_required not enforced, even though the namespace policy requires it. Topic-level policies that could not be loaded are also not applied.\n\nWhile the encryption requirement is not enforced, an authenticated client with permission to produce to the affected topic can publish messages that are not encrypted, and the broker accepts and stores them. This applies both to producers created after the topic was loaded and to producers that were already connected. Messages published with encryption remain encrypted; the issue does not expose the content of encrypted messages or the encryption keys.\n\nThe condition is not limited to transient failures. If the cause of the initialization failure persists, the encryption requirement is disabled again each time the topic is loaded, for example after a topic unload, a namespace bundle reassignment or a broker restart. An update to the namespace policies restores enforcement on a loaded topic, but only until the topic is loaded again. Enforcement is reliably restored only once the underlying cause of the failure has been resolved and the topic has been loaded again. The broker logs a warning when the encryption requirement is disabled, but the topic load is reported as successful and the state of the encryption requirement is not shown in the topic statistics.\n\nIn fixed versions, a failure during topic initialization causes the topic load to fail so that it can be retried, instead of loading the topic with the encryption requirement disabled.\n\nThis issue affects Apache Pulsar versions from 1.22.0-incubating before 4.0.14 and from 4.1.0 before 4.2.5.\n\n- 4.0.x version users should upgrade to at least 4.0.14.\n- 4.1.x and 4.2.x version users should upgrade to at least 4.2.5.\n\nUsers operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions.\n\nThe currently supported Apache Pulsar release lines are 4.0.x and 5.0.x. The supported versions schedule is available at https://pulsar.apache.org/contribute/release-policy/.\n\nUsers who rely on encryption_required and cannot upgrade immediately can monitor the broker logs for warnings containing \"isEncryptionRequired will be set to false\" (the exact wording of the message differs between releases), resolve the underlying cause of the failure, and then reload the affected topic and confirm that the warning does not recur."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 2.3,
"baseSeverity": "LOW",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "LOW",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-636",
"description": "CWE-636 Not Failing Securely (\u0027Failing Open\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-21T18:07:43.954Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://pulsar.apache.org/security/CVE-2026-105933/"
},
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread.html/f9xdlh72zf7got2y3vxww5fv4rxvmjbq"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Apache Pulsar: Namespace encryption requirement not enforced after a failure during topic initialization",
"x_generator": {
"engine": "Vulnogram 1.0.3"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-105933",
"datePublished": "2026-10-21T18:07:43.954Z",
"dateReserved": "2026-10-06T06:41:07.880Z",
"dateUpdated": "2026-10-23T22:00:14.676Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-103510 (GCVE-0-2026-103510)
Vulnerability from cvelistv5 – Published: 2026-10-05 08:44 – Updated: 2026-10-05 12:17
VLAI
EPSS
VEX
Title
Authentication bypass via blank auth token in P4Search
Summary
P4 Search prior to 2026.4.2 does not fail securely when its service authentication token is blank. In affected configurations, an unauthenticated attacker with network access can obtain the highest application privilege, potentially leading to compromise of P4 Search and the connected P4 Server.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-05 12:17 UTC
CWE
- CWE-636 - Not Failing Securely ('Failing Open')
Assigner
Perforce
CNA
References
1 reference
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Perforce | P4 (Helix Core) |
Affected:
0 , ≤ 2026.4.1
(custom)
Unaffected: 2026.4.2 (custom) |
Date Public
2026-09-30 18:29
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-103510",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-05T12:17:31.735930Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-05T12:17:56.278Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "affected",
"packageName": "P4Search",
"product": "P4 (Helix Core)",
"vendor": "Perforce",
"versions": [
{
"lessThanOrEqual": "2026.4.1",
"status": "affected",
"version": "0",
"versionType": "custom"
},
{
"status": "unaffected",
"version": "2026.4.2",
"versionType": "custom"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Khoa Bui (https://github.com/zenniskayy2k4) finder"
}
],
"datePublic": "2026-09-30T18:29:00.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "P4 Search prior to 2026.4.2 does not fail securely when its service authentication token is blank. In affected configurations, an unauthenticated attacker with network access can obtain the highest application privilege, potentially leading to compromise of P4 Search and the connected P4 Server.\u003cbr\u003e"
}
],
"value": "P4 Search prior to 2026.4.2 does not fail securely when its service authentication token is blank. In affected configurations, an unauthenticated attacker with network access can obtain the highest application privilege, potentially leading to compromise of P4 Search and the connected P4 Server."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 9.5,
"baseSeverity": "CRITICAL",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "HIGH",
"subConfidentialityImpact": "HIGH",
"subIntegrityImpact": "HIGH",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-636",
"description": "CWE-636 Not Failing Securely (\u0027Failing Open\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-05T08:44:56.686Z",
"orgId": "ca2a266c-be2f-4d4b-92d0-47b76b1a9c4e",
"shortName": "Perforce"
},
"references": [
{
"url": "https://portal.perforce.com/s/cve/a91Qi000003FDw5IAG/authentication-bypass-via-blank-auth-token-in-p4search"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Authentication bypass via blank auth token in P4Search",
"x_generator": {
"engine": "Vulnogram 1.0.5"
}
}
},
"cveMetadata": {
"assignerOrgId": "ca2a266c-be2f-4d4b-92d0-47b76b1a9c4e",
"assignerShortName": "Perforce",
"cveId": "CVE-2026-103510",
"datePublished": "2026-10-05T08:44:56.686Z",
"dateReserved": "2026-09-30T17:38:12.196Z",
"dateUpdated": "2026-10-05T12:17:56.278Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
Mitigation
Architecture and Design
Subdivide and allocate resources and components so that a failure in one part does not affect the entire product.
No CAPEC attack patterns related to this CWE.