CWE-287
DiscouragedImproper Authentication
Abstraction: Class · Status: Draft
When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.
5964 vulnerabilities reference this CWE, most recent first.
GHSA-C74M-6P5X-CFMF
Vulnerability from github – Published: 2023-05-26 18:30 – Updated: 2024-04-04 04:21The online authentication provided by the hwKitAssistant lacks strict identity verification of applications. Successful exploitation of this vulnerability may affect availability of features,such as MeeTime.
{
"affected": [],
"aliases": [
"CVE-2023-0117"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-26T17:15:13Z",
"severity": "MODERATE"
},
"details": "The online authentication provided by the hwKitAssistant lacks strict identity verification of applications. Successful exploitation of this vulnerability may affect availability of features,such as MeeTime.",
"id": "GHSA-c74m-6p5x-cfmf",
"modified": "2024-04-04T04:21:07Z",
"published": "2023-05-26T18:30:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0117"
},
{
"type": "WEB",
"url": "https://consumer.huawei.com/en/support/bulletin/2023/5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-C787-VQ26-34F6
Vulnerability from github – Published: 2022-05-13 01:46 – Updated: 2022-05-13 01:46A vulnerability in the management of shell user accounts for Cisco Policy Suite (CPS) Software for CPS appliances could allow an authenticated, local attacker to gain elevated privileges on an affected system. The affected privilege level is not at the root level. The vulnerability is due to incorrect role-based access control (RBAC) for shell user accounts. An attacker could exploit this vulnerability by authenticating to an affected appliance and providing crafted user input via the CLI. A successful exploit could allow the attacker to acquire a higher privilege level than should have been granted. To exploit this vulnerability, the attacker must log in to the appliance with valid credentials. Cisco Bug IDs: CSCve37724. Known Affected Releases: 9.0.0, 9.1.0, 10.0.0, 11.0.0, 12.0.0.
{
"affected": [],
"aliases": [
"CVE-2017-6781"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-08-17T20:29:00Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the management of shell user accounts for Cisco Policy Suite (CPS) Software for CPS appliances could allow an authenticated, local attacker to gain elevated privileges on an affected system. The affected privilege level is not at the root level. The vulnerability is due to incorrect role-based access control (RBAC) for shell user accounts. An attacker could exploit this vulnerability by authenticating to an affected appliance and providing crafted user input via the CLI. A successful exploit could allow the attacker to acquire a higher privilege level than should have been granted. To exploit this vulnerability, the attacker must log in to the appliance with valid credentials. Cisco Bug IDs: CSCve37724. Known Affected Releases: 9.0.0, 9.1.0, 10.0.0, 11.0.0, 12.0.0.",
"id": "GHSA-c787-vq26-34f6",
"modified": "2022-05-13T01:46:47Z",
"published": "2022-05-13T01:46:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-6781"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20170816-cps"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/100365"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-C79J-MJVV-WX7F
Vulnerability from github – Published: 2022-05-13 01:38 – Updated: 2022-05-13 01:38A vulnerability in the implementation of the Locator/ID Separation Protocol (LISP) in Cisco IOS XE 3.2 through 16.5 could allow an unauthenticated, remote attacker using an x tunnel router to bypass authentication checks performed when registering an Endpoint Identifier (EID) to a Routing Locator (RLOC) in the map server/map resolver (MS/MR). The vulnerability is due to a logic error introduced via a code regression for the affected software. An attacker could exploit this vulnerability by sending specific valid map-registration requests, which will be accepted by the MS/MR even if the authentication keys do not match, to the affected software. A successful exploit could allow the attacker to inject invalid mappings of EIDs to RLOCs in the MS/MR of the affected software. This vulnerability affects Cisco devices that are configured with LISP acting as an IPv4 or IPv6 map server. This vulnerability affects Cisco IOS XE Software release trains 3.9E and Everest 16.4. Cisco Bug IDs: CSCvc18008.
{
"affected": [],
"aliases": [
"CVE-2017-12236"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-09-29T01:34:00Z",
"severity": "CRITICAL"
},
"details": "A vulnerability in the implementation of the Locator/ID Separation Protocol (LISP) in Cisco IOS XE 3.2 through 16.5 could allow an unauthenticated, remote attacker using an x tunnel router to bypass authentication checks performed when registering an Endpoint Identifier (EID) to a Routing Locator (RLOC) in the map server/map resolver (MS/MR). The vulnerability is due to a logic error introduced via a code regression for the affected software. An attacker could exploit this vulnerability by sending specific valid map-registration requests, which will be accepted by the MS/MR even if the authentication keys do not match, to the affected software. A successful exploit could allow the attacker to inject invalid mappings of EIDs to RLOCs in the MS/MR of the affected software. This vulnerability affects Cisco devices that are configured with LISP acting as an IPv4 or IPv6 map server. This vulnerability affects Cisco IOS XE Software release trains 3.9E and Everest 16.4. Cisco Bug IDs: CSCvc18008.",
"id": "GHSA-c79j-mjvv-wx7f",
"modified": "2022-05-13T01:38:04Z",
"published": "2022-05-13T01:38:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-12236"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20170927-lisp"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/101033"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1039448"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C7CC-J2GP-895V
Vulnerability from github – Published: 2022-05-14 01:38 – Updated: 2022-05-14 01:38SV3C L-SERIES HD CAMERA V2.3.4.2103-S50-NTD-B20170508B devices improperly identifies users only by the authentication level sent in the cookies, which allow remote attackers to bypass authentication and gain administrator access by setting the authLevel cookie to 255.
{
"affected": [],
"aliases": [
"CVE-2018-12666"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-10-19T22:29:00Z",
"severity": "CRITICAL"
},
"details": "SV3C L-SERIES HD CAMERA V2.3.4.2103-S50-NTD-B20170508B devices improperly identifies users only by the authentication level sent in the cookies, which allow remote attackers to bypass authentication and gain administrator access by setting the authLevel cookie to 255.",
"id": "GHSA-c7cc-j2gp-895v",
"modified": "2022-05-14T01:38:49Z",
"published": "2022-05-14T01:38:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-12666"
},
{
"type": "WEB",
"url": "https://www.bishopfox.com/news/2018/10/sv3c-l-series-hd-camera-multiple-vulnerabilities"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C7H4-VHW8-GQ22
Vulnerability from github – Published: 2022-05-13 01:48 – Updated: 2022-05-13 01:48Mimo Baby 2 devices do not use authentication or encryption for the Bluetooth Low Energy (BLE) communication from a Turtle to a Lilypad, which allows attackers to inject fake information about the position and temperature of a baby via a replay or spoofing attack.
{
"affected": [],
"aliases": [
"CVE-2018-10825"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-05-15T04:29:00Z",
"severity": "MODERATE"
},
"details": "Mimo Baby 2 devices do not use authentication or encryption for the Bluetooth Low Energy (BLE) communication from a Turtle to a Lilypad, which allows attackers to inject fake information about the position and temperature of a baby via a replay or spoofing attack.",
"id": "GHSA-c7h4-vhw8-gq22",
"modified": "2022-05-13T01:48:57Z",
"published": "2022-05-13T01:48:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-10825"
},
{
"type": "WEB",
"url": "https://medium.com/@victor_14768/mimo-baby-hack-ac7fa0ae3bfb"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-C7H6-44JF-QVJM
Vulnerability from github – Published: 2022-05-24 17:44 – Updated: 2022-06-29 00:00Improper access control vulnerability in Custom App of Cybozu Office 10.0.0 to 10.8.4 allows authenticated attackers to bypass access restriction and obtain the date of Custom App via unspecified vectors.
{
"affected": [],
"aliases": [
"CVE-2021-20634"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-03-18T01:15:00Z",
"severity": "MODERATE"
},
"details": "Improper access control vulnerability in Custom App of Cybozu Office 10.0.0 to 10.8.4 allows authenticated attackers to bypass access restriction and obtain the date of Custom App via unspecified vectors.",
"id": "GHSA-c7h6-44jf-qvjm",
"modified": "2022-06-29T00:00:41Z",
"published": "2022-05-24T17:44:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20634"
},
{
"type": "WEB",
"url": "https://jvn.jp/en/jp/JVN45797538/index.html"
},
{
"type": "WEB",
"url": "https://kb.cybozu.support/article/36865"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-C7V8-6M32-34M3
Vulnerability from github – Published: 2022-05-24 17:46 – Updated: 2022-05-24 17:46An issue was discovered in MediaWiki before 1.31.12 and 1.32.x through 1.35.x before 1.35.2. Blocked users are unable to use Special:ResetTokens. This has security relevance because a blocked user might have accidentally shared a token, or might know that a token has been compromised, and yet is not able to block any potential future use of the token by an unauthorized party.
{
"affected": [],
"aliases": [
"CVE-2021-30158"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-04-06T07:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in MediaWiki before 1.31.12 and 1.32.x through 1.35.x before 1.35.2. Blocked users are unable to use Special:ResetTokens. This has security relevance because a blocked user might have accidentally shared a token, or might know that a token has been compromised, and yet is not able to block any potential future use of the token by an unauthorized party.",
"id": "GHSA-c7v8-6m32-34m3",
"modified": "2022-05-24T17:46:42Z",
"published": "2022-05-24T17:46:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-30158"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2021/05/msg00003.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2021/05/msg00006.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/26UJGHF7LJDOCQN6A3Z4PM7PYRKENJHE"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/2OMSV7B2TCFBOCICN3B4SMQP5HVRJQIT"
},
{
"type": "WEB",
"url": "https://phabricator.wikimedia.org/T277009"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202107-40"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2021/dsa-4889"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-C7XW-P58W-H6FJ
Vulnerability from github – Published: 2023-07-18 19:12 – Updated: 2023-07-18 19:12Impersonation and lockout are possible due to email trust not being handled correctly in Keycloak. Since the verified state is not reset when the email changes, it is possible for users to shadow others with the same email and lock out or impersonate them.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.keycloak:keycloak-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "22.0.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-0105"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-841"
],
"github_reviewed": true,
"github_reviewed_at": "2023-07-18T19:12:28Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "Impersonation and lockout are possible due to email trust not being handled correctly in Keycloak. Since the verified state is not reset when the email changes, it is possible for users to shadow others with the same email and lock out or impersonate them.",
"id": "GHSA-c7xw-p58w-h6fj",
"modified": "2023-07-18T19:12:28Z",
"published": "2023-07-18T19:12:28Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/keycloak/keycloak/security/advisories/GHSA-c7xw-p58w-h6fj"
},
{
"type": "WEB",
"url": "https://github.com/keycloak/keycloak/commit/87a50d3ba790b049e436c9925874f9b418af7988"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2023-0105"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2158910"
},
{
"type": "PACKAGE",
"url": "https://github.com/keycloak/keycloak"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Keycloak: Impersonation and lockout possible through incorrect handling of email trust"
}
GHSA-C82R-QG3W-Q5MV
Vulnerability from github – Published: 2022-05-14 01:56 – Updated: 2022-11-08 23:09Apache Solr uses a PKI based mechanism to secure inter-node communication when security is enabled. It is possible to create a specially crafted node name that does not exist as part of the cluster and point it to a malicious node. This can trick the nodes in cluster to believe that the malicious node is a member of the cluster. So, if Solr users have enabled BasicAuth authentication mechanism using the BasicAuthPlugin or if the user has implemented a custom Authentication plugin, which does not implement either "HttpClientInterceptorPlugin" or "HttpClientBuilderPlugin", his/her servers are vulnerable to this attack. Users who only use SSL without basic authentication or those who use Kerberos are not affected.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.solr:solr-core"
},
"ranges": [
{
"events": [
{
"introduced": "5.3.0"
},
{
"fixed": "5.5.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.solr:solr-core"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"fixed": "6.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2017-7660"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2022-11-08T23:09:57Z",
"nvd_published_at": "2017-07-07T19:29:00Z",
"severity": "HIGH"
},
"details": "Apache Solr uses a PKI based mechanism to secure inter-node communication when security is enabled. It is possible to create a specially crafted node name that does not exist as part of the cluster and point it to a malicious node. This can trick the nodes in cluster to believe that the malicious node is a member of the cluster. So, if Solr users have enabled BasicAuth authentication mechanism using the BasicAuthPlugin or if the user has implemented a custom Authentication plugin, which does not implement either \"HttpClientInterceptorPlugin\" or \"HttpClientBuilderPlugin\", his/her servers are vulnerable to this attack. Users who only use SSL without basic authentication or those who use Kerberos are not affected.",
"id": "GHSA-c82r-qg3w-q5mv",
"modified": "2022-11-08T23:09:57Z",
"published": "2022-05-14T01:56:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-7660"
},
{
"type": "WEB",
"url": "https://issues.apache.org/jira/browse/SOLR-10624"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/o0g7vpz5sz4yy0pyf1z94vkpv40x6h44"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20181127-0003"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Apache Solr insecure inter-node communication"
}
GHSA-C839-4QXR-J4X3
Vulnerability from github – Published: 2026-05-04 19:08 – Updated: 2026-05-08 19:26Summary
Broken TLS validation logic in the OVN database connection logic could allow connections to an attacker's OVN database.
OVN uses mTLS for authentication, so the attacker cannot actually perform a full man in the middle attack as they won't be able to authenticated with the real OVN deployment. At best they can provide a replacement empty database which Incus will briefly interact with before hitting errors due to the rest of the OVN stack not reacting to the committed changes.
Also worth noting that the OVN control plane is typically run on the same servers that run Incus, there is typically no routing involved between an Incus server and the OVN control plane, making such an attack extremely difficult to pull off in the first place.
Details
The OVN client implementations within Incus disable Go standard TLS server verification (InsecureSkipVerify: true) and replace it with custom peer-certificate verification logic. That replacement verifier does not anchor trust in the configured CA certificate. Instead, it constructs the verification root set from certificates supplied by the peer during the handshake. As a result, the configured CA is parsed but not used as the trust anchor for the final verification decision.
Although a configured CA certificate (tlsCAcert) is parsed and added to a client CA pool, that pool is not used during the final verification decision. Instead, the callback creates a fresh roots pool from the raw certificates received over the wire and verifies the presented leaf certificate against those attacker-influenced roots. No endpoint identity validation is visible in the provided verification logic.
In OVN-enabled Incus deployments that use these SSL database connection paths, this affects authenticated connections from Incus to the OVN northbound and southbound databases. Incus documents clustered OVN deployments in which the OVN distributed database runs across multiple servers, and upstream OVN documentation describes the northbound database as the interface used by the cloud management system and the southbound database as the central coordination point for logical and physical network state.
Because the custom verifier accepts peer-supplied trust anchors, an attacker able to impersonate or intercept the OVN endpoint on the management network can present a rogue self-signed certificate chain. Incus will accept this certificate as valid, collapsing the configured CA-based trust model. Because Incus exposes dedicated OVN TLS settings for a CA certificate, client certificate, and client key, the implementation clearly intends to authenticate OVN database connections using operator-supplied trust material rather than peer-supplied certificates. By abandoning the configured CA pool and instead trusting peer-supplied roots, the implementation defeats the intended authentication boundary on OVN database connections and permits endpoint impersonation by an active attacker able to intercept or stand in for the OVN database service.
In clustered OVN-backed Incus deployments, this flaw reduces CA-anchored authentication of OVN database connections to endpoint impersonation for an attacker with a suitable position on the management or control-plane network. This is especially significant because OVN northbound and southbound databases are the authoritative control-plane interfaces for logical network configuration, translation, and distribution to hypervisors and gateways. As a result, the issue is best understood as a control-plane authentication failure with potentially broad networking impact, not merely as generic TLS misconfiguration.
Affected Files: https://github.com/lxc/incus/blob/v6.22.0/internal/server/network/ovn/ovn_nb.go https://github.com/lxc/incus/blob/v6.22.0/internal/server/network/ovn/ovn_sb.go https://github.com/lxc/incus/blob/v6.22.0/internal/server/network/ovn/ovn_icnb.go https://github.com/lxc/incus/blob/v6.22.0/internal/server/network/ovn/ovn_icsb.go
Affected Code:
func NewNB(dbAddr string, sslCACert string, sslClientCert string, sslClientKey string) (*NB, error) {
[...]
if strings.Contains(dbAddr, "ssl:") {
[...]
tlsConfig := &tls.Config{
Certificates: []tls.Certificate{clientCert},
InsecureSkipVerify: true,
}
if sslCACert != "" {
[...]
tlsCAcert, err := x509.ParseCertificate(tlsCAder.Bytes)
if err != nil {
return nil, err
}
tlsCAcert.IsCA = true
tlsCAcert.KeyUsage = x509.KeyUsageCertSign
clientCAPool := x509.NewCertPool()
clientCAPool.AddCert(tlsCAcert)
tlsConfig.VerifyPeerCertificate = func(rawCerts [][]byte, chains [][]*x509.Certificate) error {
if len(rawCerts) < 1 {
return errors.New("Missing server certificate")
}
roots := x509.NewCertPool()
for _, rawCert := range rawCerts {
cert, _ := x509.ParseCertificate(rawCert)
if cert != nil {
roots.AddCert(cert)
}
}
cert, _ := x509.ParseCertificate(rawCerts[0])
if cert == nil {
return errors.New("Bad server certificate")
}
opts := x509.VerifyOptions{
Roots: roots,
}
_, err := cert.Verify(opts)
return err
}
}
options = append(options, ovsdbClient.WithTLSConfig(tlsConfig))
}
[...]
}
The same verification pattern is duplicated in the other affected files listed above.
Verification-Logic Proof of Concept
Because the vulnerability resides entirely in the certificate-verification logic, it can be demonstrated in isolation without a live interception lab. The following Go harness reproduces the effective OVN client verification logic, generates a rogue self-signed certificate, and demonstrates that the implemented trust decision accepts peer-supplied roots instead of the configured CA pool.
Commands:
cat <<'EOF' > poc_ovn_tls_roots.go
package main
import (
"crypto/ed25519"
"crypto/rand"
"crypto/x509"
"crypto/x509/pkix"
"fmt"
"math/big"
"time"
)
func main() {
pub, priv, _ := ed25519.GenerateKey(rand.Reader)
template := x509.Certificate{
SerialNumber: big.NewInt(1),
Subject: pkix.Name{
Organization: []string{"Attacker Corp MITM"},
},
NotBefore: time.Now(),
NotAfter: time.Now().Add(time.Hour),
KeyUsage: x509.KeyUsageDigitalSignature | x509.KeyUsageCertSign,
ExtKeyUsage: []x509.ExtKeyUsage{x509.ExtKeyUsageServerAuth},
BasicConstraintsValid: true,
IsCA: true,
}
rogueCertBytes, _ := x509.CreateCertificate(rand.Reader, &template, &template, pub, priv)
verifyPeerCertificate := func(rawCerts [][]byte) error {
if len(rawCerts) < 1 {
return fmt.Errorf("missing server certificate")
}
roots := x509.NewCertPool()
for _, rawCert := range rawCerts {
cert, _ := x509.ParseCertificate(rawCert)
if cert != nil {
roots.AddCert(cert)
}
}
cert, _ := x509.ParseCertificate(rawCerts[0])
if cert == nil {
return fmt.Errorf("bad server certificate")
}
opts := x509.VerifyOptions{
Roots: roots,
}
_, err := cert.Verify(opts)
return err
}
err := verifyPeerCertificate([][]byte{rogueCertBytes})
if err == nil {
fmt.Println("[!] VULNERABLE: The reproduced OVN client verification logic accepted the rogue attacker certificate.")
} else {
fmt.Printf("Safe: Rejected with error: %v\n", err)
}
}
EOF
go run poc_ovn_tls_roots.go
Result:
[!] VULNERABLE: The reproduced OVN client verification logic accepted the rogue attacker certificate.
It is recommended to verify peer certificates against the configured CA pool rather than against roots synthesized from untrusted peer input. The safest fix is to remove the custom VerifyPeerCertificate logic and rely on Go standard TLS verification with tls.Config.RootCAs set to the configured CA pool and, where applicable, ServerName set appropriately for identity validation.
Credit
This issue was discovered and reported by the team at 7asecurity (https://7asecurity.com/)
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/lxc/incus/v6/cmd/incusd"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "7.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-40243"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-295"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-04T19:08:01Z",
"nvd_published_at": "2026-05-06T21:16:01Z",
"severity": "LOW"
},
"details": "### Summary\nBroken TLS validation logic in the OVN database connection logic could allow connections to an attacker\u0027s OVN database.\n\nOVN uses mTLS for authentication, so the attacker cannot actually perform a full man in the middle attack as they won\u0027t be able to authenticated with the real OVN deployment. At best they can provide a replacement empty database which Incus will briefly interact with before hitting errors due to the rest of the OVN stack not reacting to the committed changes.\n\nAlso worth noting that the OVN control plane is typically run on the same servers that run Incus, there is typically no routing involved between an Incus server and the OVN control plane, making such an attack extremely difficult to pull off in the first place.\n\n### Details\nThe OVN client implementations within Incus disable Go standard TLS server verification (InsecureSkipVerify: true) and replace it with custom peer-certificate verification logic. That replacement verifier does not anchor trust in the configured CA certificate. Instead, it constructs the verification root set from certificates supplied by the peer during the handshake. As a result, the configured CA is parsed but not used as the trust anchor for the final verification decision.\n\nAlthough a configured CA certificate (tlsCAcert) is parsed and added to a client CA pool, that pool is not used during the final verification decision. Instead, the callback creates a fresh roots pool from the raw certificates received over the wire and verifies the presented leaf certificate against those attacker-influenced roots. No endpoint identity validation is visible in the provided verification logic.\n\nIn OVN-enabled Incus deployments that use these SSL database connection paths, this affects authenticated connections from Incus to the OVN northbound and southbound databases. Incus documents clustered OVN deployments in which the OVN distributed database runs across multiple servers, and upstream OVN documentation describes the northbound database as the interface used by the cloud management system and the southbound database as the central coordination point for logical and physical network state.\n\nBecause the custom verifier accepts peer-supplied trust anchors, an attacker able to impersonate or intercept the OVN endpoint on the management network can present a rogue self-signed certificate chain. Incus will accept this certificate as valid, collapsing the configured CA-based trust model. Because Incus exposes dedicated OVN TLS settings for a CA certificate, client certificate, and client key, the implementation clearly intends to authenticate OVN database connections using operator-supplied trust material rather than peer-supplied certificates. By abandoning the configured CA pool and instead trusting peer-supplied roots, the implementation defeats the intended authentication boundary on OVN database connections and permits endpoint impersonation by an active attacker able to intercept or stand in for the OVN database service.\n\nIn clustered OVN-backed Incus deployments, this flaw reduces CA-anchored authentication of OVN database connections to endpoint impersonation for an attacker with a suitable position on the management or control-plane network. This is especially significant because OVN northbound and southbound databases are the authoritative control-plane interfaces for logical network configuration, translation, and distribution to hypervisors and gateways. As a result, the issue is best understood as a control-plane authentication failure with potentially broad networking impact, not merely as generic TLS misconfiguration.\n\nAffected Files:\nhttps://github.com/lxc/incus/blob/v6.22.0/internal/server/network/ovn/ovn_nb.go \nhttps://github.com/lxc/incus/blob/v6.22.0/internal/server/network/ovn/ovn_sb.go \nhttps://github.com/lxc/incus/blob/v6.22.0/internal/server/network/ovn/ovn_icnb.go \nhttps://github.com/lxc/incus/blob/v6.22.0/internal/server/network/ovn/ovn_icsb.go \n\nAffected Code:\n```\nfunc NewNB(dbAddr string, sslCACert string, sslClientCert string, sslClientKey string) (*NB, error) {\n [...]\n if strings.Contains(dbAddr, \"ssl:\") {\n [...]\n tlsConfig := \u0026tls.Config{\n Certificates: []tls.Certificate{clientCert},\n InsecureSkipVerify: true,\n }\n\n if sslCACert != \"\" {\n [...]\n tlsCAcert, err := x509.ParseCertificate(tlsCAder.Bytes)\n if err != nil {\n return nil, err\n }\n\n tlsCAcert.IsCA = true\n tlsCAcert.KeyUsage = x509.KeyUsageCertSign\n\n clientCAPool := x509.NewCertPool()\n clientCAPool.AddCert(tlsCAcert)\n\n tlsConfig.VerifyPeerCertificate = func(rawCerts [][]byte, chains [][]*x509.Certificate) error {\n if len(rawCerts) \u003c 1 {\n return errors.New(\"Missing server certificate\")\n }\n\n roots := x509.NewCertPool()\n for _, rawCert := range rawCerts {\n cert, _ := x509.ParseCertificate(rawCert)\n if cert != nil {\n roots.AddCert(cert)\n }\n }\n\n cert, _ := x509.ParseCertificate(rawCerts[0])\n if cert == nil {\n return errors.New(\"Bad server certificate\")\n }\n\n opts := x509.VerifyOptions{\n Roots: roots,\n }\n\n _, err := cert.Verify(opts)\n return err\n }\n }\n\n options = append(options, ovsdbClient.WithTLSConfig(tlsConfig))\n }\n [...]\n}\n```\n\nThe same verification pattern is duplicated in the other affected files listed above.\n\nVerification-Logic Proof of Concept\n\nBecause the vulnerability resides entirely in the certificate-verification logic, it can be demonstrated in isolation without a live interception lab. The following Go harness reproduces the effective OVN client verification logic, generates a rogue self-signed certificate, and demonstrates that the implemented trust decision accepts peer-supplied roots instead of the configured CA pool.\n\nCommands:\n```\ncat \u003c\u003c\u0027EOF\u0027 \u003e poc_ovn_tls_roots.go\npackage main\n\nimport (\n \"crypto/ed25519\"\n \"crypto/rand\"\n \"crypto/x509\"\n \"crypto/x509/pkix\"\n \"fmt\"\n \"math/big\"\n \"time\"\n)\n\nfunc main() {\n pub, priv, _ := ed25519.GenerateKey(rand.Reader)\n\n template := x509.Certificate{\n SerialNumber: big.NewInt(1),\n Subject: pkix.Name{\n Organization: []string{\"Attacker Corp MITM\"},\n },\n NotBefore: time.Now(),\n NotAfter: time.Now().Add(time.Hour),\n KeyUsage: x509.KeyUsageDigitalSignature | x509.KeyUsageCertSign,\n ExtKeyUsage: []x509.ExtKeyUsage{x509.ExtKeyUsageServerAuth},\n BasicConstraintsValid: true,\n IsCA: true,\n }\n\n rogueCertBytes, _ := x509.CreateCertificate(rand.Reader, \u0026template, \u0026template, pub, priv)\n\n verifyPeerCertificate := func(rawCerts [][]byte) error {\n if len(rawCerts) \u003c 1 {\n return fmt.Errorf(\"missing server certificate\")\n }\n\n roots := x509.NewCertPool()\n for _, rawCert := range rawCerts {\n cert, _ := x509.ParseCertificate(rawCert)\n if cert != nil {\n roots.AddCert(cert)\n }\n }\n\n cert, _ := x509.ParseCertificate(rawCerts[0])\n if cert == nil {\n return fmt.Errorf(\"bad server certificate\")\n }\n\n opts := x509.VerifyOptions{\n Roots: roots,\n }\n\n _, err := cert.Verify(opts)\n return err\n }\n\n err := verifyPeerCertificate([][]byte{rogueCertBytes})\n if err == nil {\n fmt.Println(\"[!] VULNERABLE: The reproduced OVN client verification logic accepted the rogue attacker certificate.\")\n } else {\n fmt.Printf(\"Safe: Rejected with error: %v\\n\", err)\n }\n}\nEOF\n\ngo run poc_ovn_tls_roots.go\n```\n\nResult:\n```\n[!] VULNERABLE: The reproduced OVN client verification logic accepted the rogue attacker certificate.\n```\n\nIt is recommended to verify peer certificates against the configured CA pool rather than against roots synthesized from untrusted peer input. The safest fix is to remove the custom VerifyPeerCertificate logic and rely on Go standard TLS verification with tls.Config.RootCAs set to the configured CA pool and, where applicable, ServerName set appropriately for identity validation.\n\n### Credit\nThis issue was discovered and reported by the team at 7asecurity (https://7asecurity.com/)",
"id": "GHSA-c839-4qxr-j4x3",
"modified": "2026-05-08T19:26:41Z",
"published": "2026-05-04T19:08:01Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/lxc/incus/security/advisories/GHSA-c839-4qxr-j4x3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40243"
},
{
"type": "PACKAGE",
"url": "https://github.com/lxc/incus"
},
{
"type": "WEB",
"url": "https://github.com/lxc/incus/blob/v6.22.0/internal/server/network/ovn/ovn_icnb.go"
},
{
"type": "WEB",
"url": "https://github.com/lxc/incus/blob/v6.22.0/internal/server/network/ovn/ovn_icsb.go"
},
{
"type": "WEB",
"url": "https://github.com/lxc/incus/blob/v6.22.0/internal/server/network/ovn/ovn_nb.go"
},
{
"type": "WEB",
"url": "https://github.com/lxc/incus/blob/v6.22.0/internal/server/network/ovn/ovn_sb.go"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:A/AC:H/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Incus has an OVN TLS Verification that Accepts Peer-Supplied Roots"
}
Mitigation
Strategy: Libraries or Frameworks
Use an authentication framework or library such as the OWASP ESAPI Authentication feature.
CAPEC-114: Authentication Abuse
An attacker obtains unauthorized access to an application, service or device either through knowledge of the inherent weaknesses of an authentication mechanism, or by exploiting a flaw in the authentication scheme's implementation. In such an attack an authentication mechanism is functioning but a carefully controlled sequence of events causes the mechanism to grant access to the attacker.
CAPEC-115: Authentication Bypass
An attacker gains access to application, service, or device with the privileges of an authorized or privileged user by evading or circumventing an authentication mechanism. The attacker is therefore able to access protected data without authentication ever having taken place.
CAPEC-151: Identity Spoofing
Identity Spoofing refers to the action of assuming (i.e., taking on) the identity of some other entity (human or non-human) and then using that identity to accomplish a goal. An adversary may craft messages that appear to come from a different principle or use stolen / spoofed authentication credentials.
CAPEC-194: Fake the Source of Data
An adversary takes advantage of improper authentication to provide data or services under a falsified identity. The purpose of using the falsified identity may be to prevent traceability of the provided data or to assume the rights granted to another individual. One of the simplest forms of this attack would be the creation of an email message with a modified "From" field in order to appear that the message was sent from someone other than the actual sender. The root of the attack (in this case the email system) fails to properly authenticate the source and this results in the reader incorrectly performing the instructed action. Results of the attack vary depending on the details of the attack, but common results include privilege escalation, obfuscation of other attacks, and data corruption/manipulation.
CAPEC-22: Exploiting Trust in Client
An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.
CAPEC-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data
This attack utilizes a REST(REpresentational State Transfer)-style applications' trust in the system resources and environment to obtain sensitive data once SSL is terminated.
CAPEC-593: Session Hijacking
This type of attack involves an adversary that exploits weaknesses in an application's use of sessions in performing authentication. The adversary is able to steal or manipulate an active session and use it to gain unathorized access to the application.
CAPEC-633: Token Impersonation
An adversary exploits a weakness in authentication to create an access token (or equivalent) that impersonates a different entity, and then associates a process/thread to that that impersonated token. This action causes a downstream user to make a decision or take action that is based on the assumed identity, and not the response that blocks the adversary.
CAPEC-650: Upload a Web Shell to a Web Server
By exploiting insufficient permissions, it is possible to upload a web shell to a web server in such a way that it can be executed remotely. This shell can have various capabilities, thereby acting as a "gateway" to the underlying web server. The shell might execute at the higher permission level of the web server, providing the ability the execute malicious code at elevated levels.
CAPEC-94: Adversary in the Middle (AiTM)
An adversary targets the communication between two components (typically client and server), in order to alter or obtain data from transactions. A general approach entails the adversary placing themself within the communication channel between the two components.