Search criteria
7 vulnerabilities found for Kea DHCP by ISC
CERTFR-2025-AVI-0734
Vulnerability from certfr_avis - Published: - Updated:
Une vulnérabilité a été découverte dans ISC Kea DHCP. Elle permet à un attaquant de provoquer un déni de service à distance.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
Impacted products
References
| Title | Publication Time | Tags | |||
|---|---|---|---|---|---|
|
|||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Kea DHCP versions 2.7.x et 3.0.x ant\u00e9rieures \u00e0 3.0.1",
"product": {
"name": "Kea DHCP",
"vendor": {
"name": "ISC",
"scada": false
}
}
},
{
"description": "Kea DHCP versions 3.1.x ant\u00e9rieures \u00e0 3.1.1",
"product": {
"name": "Kea DHCP",
"vendor": {
"name": "ISC",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2025-40779",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40779"
}
],
"links": [],
"reference": "CERTFR-2025-AVI-0734",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2025-08-28T00:00:00.000000"
}
],
"risks": [
{
"description": "D\u00e9ni de service \u00e0 distance"
}
],
"summary": "Une vuln\u00e9rabilit\u00e9 a \u00e9t\u00e9 d\u00e9couverte dans ISC Kea DHCP. Elle permet \u00e0 un attaquant de provoquer un d\u00e9ni de service \u00e0 distance.",
"title": "Vuln\u00e9rabilit\u00e9 dans ISC Kea DHCP",
"vendor_advisories": [
{
"published_at": "2025-08-27",
"title": "Bulletin de s\u00e9curit\u00e9 ISC cve-2025-40779",
"url": "https://kb.isc.org/v1/docs/cve-2025-40779"
}
]
}
CERTFR-2025-AVI-0459
Vulnerability from certfr_avis - Published: - Updated:
De multiples vulnérabilités ont été découvertes dans ISC Kea DHCP. Certaines d'entre elles permettent à un attaquant de provoquer une élévation de privilèges, une atteinte à la confidentialité des données et une atteinte à l'intégrité des données.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
Impacted products
References
| Title | Publication Time | Tags | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Kea DHCP versions ant\u00e9rieures \u00e0 2.4.2",
"product": {
"name": "Kea DHCP",
"vendor": {
"name": "ISC",
"scada": false
}
}
},
{
"description": "Kea DHCP versions ant\u00e9rieures \u00e0 2.6.3",
"product": {
"name": "Kea DHCP",
"vendor": {
"name": "ISC",
"scada": false
}
}
},
{
"description": "Kea DHCP versions ant\u00e9rieures \u00e0 2.7.9",
"product": {
"name": "Kea DHCP",
"vendor": {
"name": "ISC",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2025-32801",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32801"
},
{
"name": "CVE-2025-32802",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32802"
},
{
"name": "CVE-2025-32803",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32803"
}
],
"links": [],
"reference": "CERTFR-2025-AVI-0459",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2025-05-30T00:00:00.000000"
}
],
"risks": [
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans ISC Kea DHCP. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une \u00e9l\u00e9vation de privil\u00e8ges, une atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es et une atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans ISC Kea DHCP",
"vendor_advisories": [
{
"published_at": "2025-05-28",
"title": "Bulletin de s\u00e9curit\u00e9 ISC Kea DHCP cve-2025-32802",
"url": "https://kb.isc.org/v1/docs/cve-2025-32802"
},
{
"published_at": "2025-05-28",
"title": "Bulletin de s\u00e9curit\u00e9 ISC Kea DHCP cve-2025-32803",
"url": "https://kb.isc.org/v1/docs/cve-2025-32803"
},
{
"published_at": "2025-05-28",
"title": "Bulletin de s\u00e9curit\u00e9 ISC Kea DHCP cve-2025-32801",
"url": "https://kb.isc.org/v1/docs/cve-2025-32801"
}
]
}
VAR-201910-0309
Vulnerability from variot - Updated: 2023-12-18 12:56A missing check on incoming client requests can be exploited to cause a situation where the Kea server's lease storage contains leases which are rejected as invalid when the server tries to load leases from storage on restart. If the number of such leases exceeds a hard-coded limit in the Kea code, a server trying to restart will conclude that there is a problem with its lease store and give up. Versions affected: 1.4.0 to 1.5.0, 1.6.0-beta1, and 1.6.0-beta2. ISC (Internet Systems Consortium) Provided by Kea DHCP The server has a service disruption (DoS) Vulnerabilities exist. Kea DHCP The server contains several vulnerabilities: * DHCPv6 Malformed format when operating on server DUID With packets containing Kea DHCPv6 server process (kea-dhcp6) Ends - CVE-2019-6472 * DHCPv4 While operating on the server hostname Depending on options assertion failure Occurs, Kea DHCPv4 server process (kea-dhcp4) Ends - CVE-2019-6473 * As a storage location for lease information memfile Is specified, if invalid lease information is stored in the storage more than a certain number Kea Server cannot be restarted - CVE-2019-6474Service disruption by a third party who can access the network to which the product is connected (DoS) An attack may be carried out. ISC Kea DHCP is an open source DHCP (Dynamic Host Configuration Protocol) server from the American ISC Corporation.
An input validation error vulnerability exists in ISC Kea DHCP versions 1.4.0 to 1.5.0, 1.6.0-beta1, and 1.6.0-beta2. The vulnerability stems from a network system or product that did not properly validate the input data
Show details on source website{
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/VARIoTentry#",
"affected_products": {
"@id": "https://www.variotdbs.pl/ref/affected_products"
},
"configurations": {
"@id": "https://www.variotdbs.pl/ref/configurations"
},
"credits": {
"@id": "https://www.variotdbs.pl/ref/credits"
},
"cvss": {
"@id": "https://www.variotdbs.pl/ref/cvss/"
},
"description": {
"@id": "https://www.variotdbs.pl/ref/description/"
},
"exploit_availability": {
"@id": "https://www.variotdbs.pl/ref/exploit_availability/"
},
"external_ids": {
"@id": "https://www.variotdbs.pl/ref/external_ids/"
},
"iot": {
"@id": "https://www.variotdbs.pl/ref/iot/"
},
"iot_taxonomy": {
"@id": "https://www.variotdbs.pl/ref/iot_taxonomy/"
},
"patch": {
"@id": "https://www.variotdbs.pl/ref/patch/"
},
"problemtype_data": {
"@id": "https://www.variotdbs.pl/ref/problemtype_data/"
},
"references": {
"@id": "https://www.variotdbs.pl/ref/references/"
},
"sources": {
"@id": "https://www.variotdbs.pl/ref/sources/"
},
"sources_release_date": {
"@id": "https://www.variotdbs.pl/ref/sources_release_date/"
},
"sources_update_date": {
"@id": "https://www.variotdbs.pl/ref/sources_update_date/"
},
"threat_type": {
"@id": "https://www.variotdbs.pl/ref/threat_type/"
},
"title": {
"@id": "https://www.variotdbs.pl/ref/title/"
},
"type": {
"@id": "https://www.variotdbs.pl/ref/type/"
}
},
"@id": "https://www.variotdbs.pl/vuln/VAR-201910-0309",
"affected_products": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/affected_products#",
"data": {
"@container": "@list"
},
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
},
"@id": "https://www.variotdbs.pl/ref/sources"
}
},
"data": [
{
"model": "kea",
"scope": "gte",
"trust": 1.0,
"vendor": "isc",
"version": "1.4.0"
},
{
"model": "kea",
"scope": "eq",
"trust": 1.0,
"vendor": "isc",
"version": "1.6.0"
},
{
"model": "kea",
"scope": "lte",
"trust": 1.0,
"vendor": "isc",
"version": "1.5.0"
},
{
"model": "kea",
"scope": "eq",
"trust": 0.8,
"vendor": "isc",
"version": "1.4.0 to 1.5.0"
},
{
"model": "kea",
"scope": "eq",
"trust": 0.8,
"vendor": "isc",
"version": "1.6.0-beta1"
},
{
"model": "kea",
"scope": "eq",
"trust": 0.8,
"vendor": "isc",
"version": "1.6.0-beta2"
},
{
"model": "kea dhcp",
"scope": "gte",
"trust": 0.6,
"vendor": "isc",
"version": "1.4.0,\u003c=1.5.0"
},
{
"model": "kea dhcp 1.6.0-beta1",
"scope": null,
"trust": 0.6,
"vendor": "isc",
"version": null
},
{
"model": "kea dhcp 1.6.0-beta2",
"scope": null,
"trust": 0.6,
"vendor": "isc",
"version": null
}
],
"sources": [
{
"db": "CNVD",
"id": "CNVD-2020-03750"
},
{
"db": "JVNDB",
"id": "JVNDB-2019-008546"
},
{
"db": "NVD",
"id": "CVE-2019-6474"
}
]
},
"configurations": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/configurations#",
"children": {
"@container": "@list"
},
"cpe_match": {
"@container": "@list"
},
"data": {
"@container": "@list"
},
"nodes": {
"@container": "@list"
}
},
"data": [
{
"CVE_data_version": "4.0",
"nodes": [
{
"children": [],
"cpe_match": [
{
"cpe23Uri": "cpe:2.3:a:isc:kea:*:*:*:*:*:*:*:*",
"cpe_name": [],
"versionEndIncluding": "1.5.0",
"versionStartIncluding": "1.4.0",
"vulnerable": true
},
{
"cpe23Uri": "cpe:2.3:a:isc:kea:1.6.0:beta2:*:*:*:*:*:*",
"cpe_name": [],
"vulnerable": true
},
{
"cpe23Uri": "cpe:2.3:a:isc:kea:1.6.0:beta1:*:*:*:*:*:*",
"cpe_name": [],
"vulnerable": true
}
],
"operator": "OR"
}
]
}
],
"sources": [
{
"db": "NVD",
"id": "CVE-2019-6474"
}
]
},
"cve": "CVE-2019-6474",
"cvss": {
"@context": {
"cvssV2": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/cvss/cvssV2#"
},
"@id": "https://www.variotdbs.pl/ref/cvss/cvssV2"
},
"cvssV3": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/cvss/cvssV3#"
},
"@id": "https://www.variotdbs.pl/ref/cvss/cvssV3/"
},
"severity": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/cvss/severity#"
},
"@id": "https://www.variotdbs.pl/ref/cvss/severity"
},
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
},
"@id": "https://www.variotdbs.pl/ref/sources"
}
},
"data": [
{
"cvssV2": [
{
"acInsufInfo": false,
"accessComplexity": "LOW",
"accessVector": "ADJACENT_NETWORK",
"authentication": "NONE",
"author": "NVD",
"availabilityImpact": "COMPLETE",
"baseScore": 6.1,
"confidentialityImpact": "NONE",
"exploitabilityScore": 6.5,
"impactScore": 6.9,
"integrityImpact": "NONE",
"obtainAllPrivilege": false,
"obtainOtherPrivilege": false,
"obtainUserPrivilege": false,
"severity": "MEDIUM",
"trust": 1.0,
"userInteractionRequired": false,
"vectorString": "AV:A/AC:L/Au:N/C:N/I:N/A:C",
"version": "2.0"
},
{
"accessComplexity": "LOW",
"accessVector": "ADJACENT_NETWORK",
"authentication": "NONE",
"author": "CNVD",
"availabilityImpact": "COMPLETE",
"baseScore": 7.3,
"confidentialityImpact": "PARTIAL",
"exploitabilityScore": 6.5,
"id": "CNVD-2020-03750",
"impactScore": 8.5,
"integrityImpact": "PARTIAL",
"severity": "HIGH",
"trust": 0.6,
"vectorString": "AV:A/AC:L/Au:N/C:P/I:P/A:C",
"version": "2.0"
}
],
"cvssV3": [
{
"attackComplexity": "LOW",
"attackVector": "ADJACENT_NETWORK",
"author": "NVD",
"availabilityImpact": "HIGH",
"baseScore": 6.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"exploitabilityScore": 2.8,
"impactScore": 3.6,
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"trust": 1.0,
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
{
"attackComplexity": "LOW",
"attackVector": "ADJACENT_NETWORK",
"author": "security-officer@isc.org",
"availabilityImpact": "HIGH",
"baseScore": 5.7,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"exploitabilityScore": 2.1,
"impactScore": 3.6,
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"trust": 1.0,
"userInteraction": "REQUIRED",
"vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"version": "3.1"
}
],
"severity": [
{
"author": "NVD",
"id": "CVE-2019-6474",
"trust": 1.0,
"value": "MEDIUM"
},
{
"author": "security-officer@isc.org",
"id": "CVE-2019-6474",
"trust": 1.0,
"value": "MEDIUM"
},
{
"author": "CNVD",
"id": "CNVD-2020-03750",
"trust": 0.6,
"value": "HIGH"
},
{
"author": "CNNVD",
"id": "CNNVD-201909-378",
"trust": 0.6,
"value": "MEDIUM"
}
]
}
],
"sources": [
{
"db": "CNVD",
"id": "CNVD-2020-03750"
},
{
"db": "NVD",
"id": "CVE-2019-6474"
},
{
"db": "NVD",
"id": "CVE-2019-6474"
},
{
"db": "CNNVD",
"id": "CNNVD-201909-378"
}
]
},
"description": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/description#",
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": "A missing check on incoming client requests can be exploited to cause a situation where the Kea server\u0027s lease storage contains leases which are rejected as invalid when the server tries to load leases from storage on restart. If the number of such leases exceeds a hard-coded limit in the Kea code, a server trying to restart will conclude that there is a problem with its lease store and give up. Versions affected: 1.4.0 to 1.5.0, 1.6.0-beta1, and 1.6.0-beta2. ISC (Internet Systems Consortium) Provided by Kea DHCP The server has a service disruption (DoS) Vulnerabilities exist. Kea DHCP The server contains several vulnerabilities: * DHCPv6 Malformed format when operating on server DUID With packets containing Kea DHCPv6 server process (kea-dhcp6) Ends - CVE-2019-6472 * DHCPv4 While operating on the server hostname Depending on options assertion failure Occurs, Kea DHCPv4 server process (kea-dhcp4) Ends - CVE-2019-6473 * As a storage location for lease information memfile Is specified, if invalid lease information is stored in the storage more than a certain number Kea Server cannot be restarted - CVE-2019-6474Service disruption by a third party who can access the network to which the product is connected (DoS) An attack may be carried out. ISC Kea DHCP is an open source DHCP (Dynamic Host Configuration Protocol) server from the American ISC Corporation. \n\r\n\r\nAn input validation error vulnerability exists in ISC Kea DHCP versions 1.4.0 to 1.5.0, 1.6.0-beta1, and 1.6.0-beta2. The vulnerability stems from a network system or product that did not properly validate the input data",
"sources": [
{
"db": "NVD",
"id": "CVE-2019-6474"
},
{
"db": "JVNDB",
"id": "JVNDB-2019-008546"
},
{
"db": "CNVD",
"id": "CNVD-2020-03750"
}
],
"trust": 2.16
},
"external_ids": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/external_ids#",
"data": {
"@container": "@list"
},
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": [
{
"db": "NVD",
"id": "CVE-2019-6474",
"trust": 3.0
},
{
"db": "JVN",
"id": "JVNVU93863470",
"trust": 0.8
},
{
"db": "JVNDB",
"id": "JVNDB-2019-008546",
"trust": 0.8
},
{
"db": "CNVD",
"id": "CNVD-2020-03750",
"trust": 0.6
},
{
"db": "CNNVD",
"id": "CNNVD-201909-378",
"trust": 0.6
}
],
"sources": [
{
"db": "CNVD",
"id": "CNVD-2020-03750"
},
{
"db": "JVNDB",
"id": "JVNDB-2019-008546"
},
{
"db": "NVD",
"id": "CVE-2019-6474"
},
{
"db": "CNNVD",
"id": "CNNVD-201909-378"
}
]
},
"id": "VAR-201910-0309",
"iot": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/iot#",
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": true,
"sources": [
{
"db": "CNVD",
"id": "CNVD-2020-03750"
}
],
"trust": 1.6
},
"iot_taxonomy": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/iot_taxonomy#",
"data": {
"@container": "@list"
},
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": [
{
"category": [
"Network device"
],
"sub_category": null,
"trust": 0.6
}
],
"sources": [
{
"db": "CNVD",
"id": "CNVD-2020-03750"
}
]
},
"last_update_date": "2023-12-18T12:56:22.189000Z",
"patch": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/patch#",
"data": {
"@container": "@list"
},
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": [
{
"title": "CVE-2019-6472: A packet containing a malformed DUID can cause the kea-dhcp6 server to terminate",
"trust": 0.8,
"url": "https://kb.isc.org/docs/cve-2019-6472"
},
{
"title": "CVE-2019-6473: An invalid hostname option can cause the kea-dhcp4 server to terminate",
"trust": 0.8,
"url": "https://kb.isc.org/docs/cve-2019-6473"
},
{
"title": "CVE-2019-6474: An oversight when validating incoming client requests can lead to a situation where the Kea server will exit when trying to restart",
"trust": 0.8,
"url": "https://kb.isc.org/docs/cve-2019-6474"
},
{
"title": "Patch for ISC Kea DHCP Input Validation Error Vulnerability",
"trust": 0.6,
"url": "https://www.cnvd.org.cn/patchinfo/show/199061"
}
],
"sources": [
{
"db": "CNVD",
"id": "CNVD-2020-03750"
},
{
"db": "JVNDB",
"id": "JVNDB-2019-008546"
}
]
},
"problemtype_data": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/problemtype_data#",
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": [
{
"problemtype": "CWE-772",
"trust": 1.0
}
],
"sources": [
{
"db": "NVD",
"id": "CVE-2019-6474"
}
]
},
"references": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/references#",
"data": {
"@container": "@list"
},
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": [
{
"trust": 1.6,
"url": "https://kb.isc.org/docs/cve-2019-6474"
},
{
"trust": 1.4,
"url": "https://nvd.nist.gov/vuln/detail/cve-2019-6474"
},
{
"trust": 1.2,
"url": "https://vigilance.fr/vulnerability/kea-dhcp-three-vulnerabilities-30273"
},
{
"trust": 0.8,
"url": "https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2019-6474"
},
{
"trust": 0.8,
"url": "https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2019-6472"
},
{
"trust": 0.8,
"url": "https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2019-6473"
},
{
"trust": 0.8,
"url": "https://jvn.jp/vu/jvnvu93863470"
},
{
"trust": 0.8,
"url": "https://nvd.nist.gov/vuln/detail/cve-2019-6472"
},
{
"trust": 0.8,
"url": "https://nvd.nist.gov/vuln/detail/cve-2019-6473"
}
],
"sources": [
{
"db": "CNVD",
"id": "CNVD-2020-03750"
},
{
"db": "JVNDB",
"id": "JVNDB-2019-008546"
},
{
"db": "NVD",
"id": "CVE-2019-6474"
},
{
"db": "CNNVD",
"id": "CNNVD-201909-378"
}
]
},
"sources": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#",
"data": {
"@container": "@list"
}
},
"data": [
{
"db": "CNVD",
"id": "CNVD-2020-03750"
},
{
"db": "JVNDB",
"id": "JVNDB-2019-008546"
},
{
"db": "NVD",
"id": "CVE-2019-6474"
},
{
"db": "CNNVD",
"id": "CNNVD-201909-378"
}
]
},
"sources_release_date": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources_release_date#",
"data": {
"@container": "@list"
}
},
"data": [
{
"date": "2020-02-05T00:00:00",
"db": "CNVD",
"id": "CNVD-2020-03750"
},
{
"date": "2019-09-03T00:00:00",
"db": "JVNDB",
"id": "JVNDB-2019-008546"
},
{
"date": "2019-10-16T18:15:37.217000",
"db": "NVD",
"id": "CVE-2019-6474"
},
{
"date": "2019-09-09T00:00:00",
"db": "CNNVD",
"id": "CNNVD-201909-378"
}
]
},
"sources_update_date": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources_update_date#",
"data": {
"@container": "@list"
}
},
"data": [
{
"date": "2020-02-05T00:00:00",
"db": "CNVD",
"id": "CNVD-2020-03750"
},
{
"date": "2019-12-02T00:00:00",
"db": "JVNDB",
"id": "JVNDB-2019-008546"
},
{
"date": "2020-08-24T17:37:01.140000",
"db": "NVD",
"id": "CVE-2019-6474"
},
{
"date": "2020-08-25T00:00:00",
"db": "CNNVD",
"id": "CNNVD-201909-378"
}
]
},
"threat_type": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/threat_type#",
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": "remote or local",
"sources": [
{
"db": "CNNVD",
"id": "CNNVD-201909-378"
}
],
"trust": 0.6
},
"title": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/title#",
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": "ISC Kea DHCP Input Validation Error Vulnerability",
"sources": [
{
"db": "CNVD",
"id": "CNVD-2020-03750"
},
{
"db": "CNNVD",
"id": "CNNVD-201909-378"
}
],
"trust": 1.2
},
"type": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/type#",
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": "input validation error",
"sources": [
{
"db": "CNNVD",
"id": "CNNVD-201909-378"
}
],
"trust": 0.6
}
}
CVE-2018-5739 (GCVE-0-2018-5739)
Vulnerability from cvelistv5 – Published: 2019-01-16 20:00 – Updated: 2024-09-17 02:11
VLAI?
Summary
An extension to hooks capabilities which debuted in Kea 1.4.0 introduced a memory leak for operators who are using certain hooks library facilities. In order to support multiple requests simultaneously, Kea 1.4 added a callout handle store but unfortunately the initial implementation of this store does not properly free memory in every case. Hooks which make use of query4 or query6 parameters in their callouts can leak memory, resulting in the eventual exhaustion of available memory and subsequent failure of the server process. Affects Kea DHCP 1.4.0.
Severity ?
6.5 (Medium)
CWE
- Only servers using hooks which make use of the callout handle store are affected. A Kea server which is using one or more hooks libraries that exhibit this problem will increase its memory use over time, with the rate of increase being proportional to the amount of DHCP traffic processed. Eventually, due to uncontrolled growth, the server will either exhaust all system memory or, if the administrator has set a per-process memory limit, will hit that limit, after which point further memory allocations will fail and the Kea server will crash. An attacker who is within the broadcast domain of the Kea server or in a network which is permitted to relay DHCP traffic to the Kea server can hasten the arrival of this outcome by deliberately sending a large volume of requests to the Kea server. Ability to deliberately trigger this vulnerability depends on the hooks libraries used and the hook points used for callouts. Our scoring for this vulnerability is based on the hook points used for hook libraries distributed by ISC and also based on the assumption that the Kea server does not accept arbitrary traffic from the internet (but is protected, e.g. by firewall, and only accepts DHCP traffic from the local broadcast domain and from nearby networks via authorized DHCP relay agents.) We cannot score every combination, but the risk could be higher to custom-developed hook libraries using other hook points or to servers which accept arbitrary DHCP traffic without restriction.
Assigner
References
| URL | Tags | ||||
|---|---|---|---|---|---|
|
|||||
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-05T05:40:51.272Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_refsource_CONFIRM",
"x_transferred"
],
"url": "https://kb.isc.org/docs/aa-01626"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"product": "Kea DHCP",
"vendor": "ISC",
"versions": [
{
"status": "affected",
"version": "Kea DHCP 1.4.0"
}
]
}
],
"datePublic": "2018-07-11T00:00:00",
"descriptions": [
{
"lang": "en",
"value": "An extension to hooks capabilities which debuted in Kea 1.4.0 introduced a memory leak for operators who are using certain hooks library facilities. In order to support multiple requests simultaneously, Kea 1.4 added a callout handle store but unfortunately the initial implementation of this store does not properly free memory in every case. Hooks which make use of query4 or query6 parameters in their callouts can leak memory, resulting in the eventual exhaustion of available memory and subsequent failure of the server process. Affects Kea DHCP 1.4.0."
}
],
"metrics": [
{
"cvssV3_0": {
"attackComplexity": "LOW",
"attackVector": "ADJACENT_NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 6.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.0"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"description": "Only servers using hooks which make use of the callout handle store are affected. A Kea server which is using one or more hooks libraries that exhibit this problem will increase its memory use over time, with the rate of increase being proportional to the amount of DHCP traffic processed. Eventually, due to uncontrolled growth, the server will either exhaust all system memory or, if the administrator has set a per-process memory limit, will hit that limit, after which point further memory allocations will fail and the Kea server will crash. \n\nAn attacker who is within the broadcast domain of the Kea server or in a network which is permitted to relay DHCP traffic to the Kea server can hasten the arrival of this outcome by deliberately sending a large volume of requests to the Kea server.\n\nAbility to deliberately trigger this vulnerability depends on the hooks libraries used and the hook points used for callouts. Our scoring for this vulnerability is based on the hook points used for hook libraries distributed by ISC and also based on the assumption that the Kea server does not accept arbitrary traffic from the internet (but is protected, e.g. by firewall, and only accepts DHCP traffic from the local broadcast domain and from nearby networks via authorized DHCP relay agents.) We cannot score every combination, but the risk could be higher to custom-developed hook libraries using other hook points or to servers which accept arbitrary DHCP traffic without restriction.",
"lang": "en",
"type": "text"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2019-01-16T19:57:01",
"orgId": "404fd4d2-a609-4245-b543-2c944a302a22",
"shortName": "isc"
},
"references": [
{
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://kb.isc.org/docs/aa-01626"
}
],
"solutions": [
{
"lang": "en",
"value": "Upgrade to Kea 1.4.0-P1 or higher, available via https://www.isc.org/downloads."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Failure to release memory may exhaust system resources",
"workarounds": [
{
"lang": "en",
"value": "+ Monitoring and routinely restarting ISC Kea DHCPv4 and DHCPv6 services may be an effective mitigation for some production environments\n + Running a new build of Kea without any hook libraries that use the callout store is another option, though it may not be a viable option where the production environment is dependent on the other hooks that need to be omitted to avoid these symptoms. These hooks distributed by ISC do not use the callout store and are safe to use: Lease Commands, Stat Commands, Host Commands (a Kea Premium hook) and Subnet Commands (a subscriber-only hook provided to Kea support customers).\n + Reverting to Kea DHCP 1.3.0 may be possible for some production environments but because of differences in the database schema operators should check carefully before attempting rollback:\n - If using memfile storage entirely, there should not be any compatibility issues.\n - If using a database solution for hosts or leases, the 1.4.0 schema will be incompatible with ISC Kea 1.3.0; the database therefore must be restored from a pre-upgrade backup for this to be successful.\n - If you are unsure whether or not you can roll back to 1.3.0 without restoring a previous version of your database, you may send an e-mail to security-officer@isc.org describing your storage setup and we will advise."
}
],
"x_legacyV4Record": {
"CVE_data_meta": {
"ASSIGNER": "security-officer@isc.org",
"DATE_PUBLIC": "2018-07-11T00:00:00.000Z",
"ID": "CVE-2018-5739",
"STATE": "PUBLIC",
"TITLE": "Failure to release memory may exhaust system resources"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "Kea DHCP",
"version": {
"version_data": [
{
"version_name": "Kea DHCP",
"version_value": "1.4.0"
}
]
}
}
]
},
"vendor_name": "ISC"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "An extension to hooks capabilities which debuted in Kea 1.4.0 introduced a memory leak for operators who are using certain hooks library facilities. In order to support multiple requests simultaneously, Kea 1.4 added a callout handle store but unfortunately the initial implementation of this store does not properly free memory in every case. Hooks which make use of query4 or query6 parameters in their callouts can leak memory, resulting in the eventual exhaustion of available memory and subsequent failure of the server process. Affects Kea DHCP 1.4.0."
}
]
},
"impact": {
"cvss": {
"attackComplexity": "LOW",
"attackVector": "ADJACENT_NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 6.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.0"
}
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "Only servers using hooks which make use of the callout handle store are affected. A Kea server which is using one or more hooks libraries that exhibit this problem will increase its memory use over time, with the rate of increase being proportional to the amount of DHCP traffic processed. Eventually, due to uncontrolled growth, the server will either exhaust all system memory or, if the administrator has set a per-process memory limit, will hit that limit, after which point further memory allocations will fail and the Kea server will crash. \n\nAn attacker who is within the broadcast domain of the Kea server or in a network which is permitted to relay DHCP traffic to the Kea server can hasten the arrival of this outcome by deliberately sending a large volume of requests to the Kea server.\n\nAbility to deliberately trigger this vulnerability depends on the hooks libraries used and the hook points used for callouts. Our scoring for this vulnerability is based on the hook points used for hook libraries distributed by ISC and also based on the assumption that the Kea server does not accept arbitrary traffic from the internet (but is protected, e.g. by firewall, and only accepts DHCP traffic from the local broadcast domain and from nearby networks via authorized DHCP relay agents.) We cannot score every combination, but the risk could be higher to custom-developed hook libraries using other hook points or to servers which accept arbitrary DHCP traffic without restriction."
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "https://kb.isc.org/docs/aa-01626",
"refsource": "CONFIRM",
"url": "https://kb.isc.org/docs/aa-01626"
}
]
},
"solution": [
{
"lang": "en",
"value": "Upgrade to Kea 1.4.0-P1 or higher, available via https://www.isc.org/downloads."
}
],
"source": {
"discovery": "UNKNOWN"
},
"work_around": [
{
"lang": "en",
"value": "+ Monitoring and routinely restarting ISC Kea DHCPv4 and DHCPv6 services may be an effective mitigation for some production environments\n + Running a new build of Kea without any hook libraries that use the callout store is another option, though it may not be a viable option where the production environment is dependent on the other hooks that need to be omitted to avoid these symptoms. These hooks distributed by ISC do not use the callout store and are safe to use: Lease Commands, Stat Commands, Host Commands (a Kea Premium hook) and Subnet Commands (a subscriber-only hook provided to Kea support customers).\n + Reverting to Kea DHCP 1.3.0 may be possible for some production environments but because of differences in the database schema operators should check carefully before attempting rollback:\n - If using memfile storage entirely, there should not be any compatibility issues.\n - If using a database solution for hosts or leases, the 1.4.0 schema will be incompatible with ISC Kea 1.3.0; the database therefore must be restored from a pre-upgrade backup for this to be successful.\n - If you are unsure whether or not you can roll back to 1.3.0 without restoring a previous version of your database, you may send an e-mail to security-officer@isc.org describing your storage setup and we will advise."
}
]
}
}
},
"cveMetadata": {
"assignerOrgId": "404fd4d2-a609-4245-b543-2c944a302a22",
"assignerShortName": "isc",
"cveId": "CVE-2018-5739",
"datePublished": "2019-01-16T20:00:00Z",
"dateReserved": "2018-01-17T00:00:00",
"dateUpdated": "2024-09-17T02:11:49.386Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
CVE-2018-5739 (GCVE-0-2018-5739)
Vulnerability from nvd – Published: 2019-01-16 20:00 – Updated: 2024-09-17 02:11
VLAI?
Summary
An extension to hooks capabilities which debuted in Kea 1.4.0 introduced a memory leak for operators who are using certain hooks library facilities. In order to support multiple requests simultaneously, Kea 1.4 added a callout handle store but unfortunately the initial implementation of this store does not properly free memory in every case. Hooks which make use of query4 or query6 parameters in their callouts can leak memory, resulting in the eventual exhaustion of available memory and subsequent failure of the server process. Affects Kea DHCP 1.4.0.
Severity ?
6.5 (Medium)
CWE
- Only servers using hooks which make use of the callout handle store are affected. A Kea server which is using one or more hooks libraries that exhibit this problem will increase its memory use over time, with the rate of increase being proportional to the amount of DHCP traffic processed. Eventually, due to uncontrolled growth, the server will either exhaust all system memory or, if the administrator has set a per-process memory limit, will hit that limit, after which point further memory allocations will fail and the Kea server will crash. An attacker who is within the broadcast domain of the Kea server or in a network which is permitted to relay DHCP traffic to the Kea server can hasten the arrival of this outcome by deliberately sending a large volume of requests to the Kea server. Ability to deliberately trigger this vulnerability depends on the hooks libraries used and the hook points used for callouts. Our scoring for this vulnerability is based on the hook points used for hook libraries distributed by ISC and also based on the assumption that the Kea server does not accept arbitrary traffic from the internet (but is protected, e.g. by firewall, and only accepts DHCP traffic from the local broadcast domain and from nearby networks via authorized DHCP relay agents.) We cannot score every combination, but the risk could be higher to custom-developed hook libraries using other hook points or to servers which accept arbitrary DHCP traffic without restriction.
Assigner
References
| URL | Tags | ||||
|---|---|---|---|---|---|
|
|||||
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-05T05:40:51.272Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_refsource_CONFIRM",
"x_transferred"
],
"url": "https://kb.isc.org/docs/aa-01626"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"product": "Kea DHCP",
"vendor": "ISC",
"versions": [
{
"status": "affected",
"version": "Kea DHCP 1.4.0"
}
]
}
],
"datePublic": "2018-07-11T00:00:00",
"descriptions": [
{
"lang": "en",
"value": "An extension to hooks capabilities which debuted in Kea 1.4.0 introduced a memory leak for operators who are using certain hooks library facilities. In order to support multiple requests simultaneously, Kea 1.4 added a callout handle store but unfortunately the initial implementation of this store does not properly free memory in every case. Hooks which make use of query4 or query6 parameters in their callouts can leak memory, resulting in the eventual exhaustion of available memory and subsequent failure of the server process. Affects Kea DHCP 1.4.0."
}
],
"metrics": [
{
"cvssV3_0": {
"attackComplexity": "LOW",
"attackVector": "ADJACENT_NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 6.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.0"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"description": "Only servers using hooks which make use of the callout handle store are affected. A Kea server which is using one or more hooks libraries that exhibit this problem will increase its memory use over time, with the rate of increase being proportional to the amount of DHCP traffic processed. Eventually, due to uncontrolled growth, the server will either exhaust all system memory or, if the administrator has set a per-process memory limit, will hit that limit, after which point further memory allocations will fail and the Kea server will crash. \n\nAn attacker who is within the broadcast domain of the Kea server or in a network which is permitted to relay DHCP traffic to the Kea server can hasten the arrival of this outcome by deliberately sending a large volume of requests to the Kea server.\n\nAbility to deliberately trigger this vulnerability depends on the hooks libraries used and the hook points used for callouts. Our scoring for this vulnerability is based on the hook points used for hook libraries distributed by ISC and also based on the assumption that the Kea server does not accept arbitrary traffic from the internet (but is protected, e.g. by firewall, and only accepts DHCP traffic from the local broadcast domain and from nearby networks via authorized DHCP relay agents.) We cannot score every combination, but the risk could be higher to custom-developed hook libraries using other hook points or to servers which accept arbitrary DHCP traffic without restriction.",
"lang": "en",
"type": "text"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2019-01-16T19:57:01",
"orgId": "404fd4d2-a609-4245-b543-2c944a302a22",
"shortName": "isc"
},
"references": [
{
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://kb.isc.org/docs/aa-01626"
}
],
"solutions": [
{
"lang": "en",
"value": "Upgrade to Kea 1.4.0-P1 or higher, available via https://www.isc.org/downloads."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Failure to release memory may exhaust system resources",
"workarounds": [
{
"lang": "en",
"value": "+ Monitoring and routinely restarting ISC Kea DHCPv4 and DHCPv6 services may be an effective mitigation for some production environments\n + Running a new build of Kea without any hook libraries that use the callout store is another option, though it may not be a viable option where the production environment is dependent on the other hooks that need to be omitted to avoid these symptoms. These hooks distributed by ISC do not use the callout store and are safe to use: Lease Commands, Stat Commands, Host Commands (a Kea Premium hook) and Subnet Commands (a subscriber-only hook provided to Kea support customers).\n + Reverting to Kea DHCP 1.3.0 may be possible for some production environments but because of differences in the database schema operators should check carefully before attempting rollback:\n - If using memfile storage entirely, there should not be any compatibility issues.\n - If using a database solution for hosts or leases, the 1.4.0 schema will be incompatible with ISC Kea 1.3.0; the database therefore must be restored from a pre-upgrade backup for this to be successful.\n - If you are unsure whether or not you can roll back to 1.3.0 without restoring a previous version of your database, you may send an e-mail to security-officer@isc.org describing your storage setup and we will advise."
}
],
"x_legacyV4Record": {
"CVE_data_meta": {
"ASSIGNER": "security-officer@isc.org",
"DATE_PUBLIC": "2018-07-11T00:00:00.000Z",
"ID": "CVE-2018-5739",
"STATE": "PUBLIC",
"TITLE": "Failure to release memory may exhaust system resources"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "Kea DHCP",
"version": {
"version_data": [
{
"version_name": "Kea DHCP",
"version_value": "1.4.0"
}
]
}
}
]
},
"vendor_name": "ISC"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "An extension to hooks capabilities which debuted in Kea 1.4.0 introduced a memory leak for operators who are using certain hooks library facilities. In order to support multiple requests simultaneously, Kea 1.4 added a callout handle store but unfortunately the initial implementation of this store does not properly free memory in every case. Hooks which make use of query4 or query6 parameters in their callouts can leak memory, resulting in the eventual exhaustion of available memory and subsequent failure of the server process. Affects Kea DHCP 1.4.0."
}
]
},
"impact": {
"cvss": {
"attackComplexity": "LOW",
"attackVector": "ADJACENT_NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 6.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.0"
}
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "Only servers using hooks which make use of the callout handle store are affected. A Kea server which is using one or more hooks libraries that exhibit this problem will increase its memory use over time, with the rate of increase being proportional to the amount of DHCP traffic processed. Eventually, due to uncontrolled growth, the server will either exhaust all system memory or, if the administrator has set a per-process memory limit, will hit that limit, after which point further memory allocations will fail and the Kea server will crash. \n\nAn attacker who is within the broadcast domain of the Kea server or in a network which is permitted to relay DHCP traffic to the Kea server can hasten the arrival of this outcome by deliberately sending a large volume of requests to the Kea server.\n\nAbility to deliberately trigger this vulnerability depends on the hooks libraries used and the hook points used for callouts. Our scoring for this vulnerability is based on the hook points used for hook libraries distributed by ISC and also based on the assumption that the Kea server does not accept arbitrary traffic from the internet (but is protected, e.g. by firewall, and only accepts DHCP traffic from the local broadcast domain and from nearby networks via authorized DHCP relay agents.) We cannot score every combination, but the risk could be higher to custom-developed hook libraries using other hook points or to servers which accept arbitrary DHCP traffic without restriction."
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "https://kb.isc.org/docs/aa-01626",
"refsource": "CONFIRM",
"url": "https://kb.isc.org/docs/aa-01626"
}
]
},
"solution": [
{
"lang": "en",
"value": "Upgrade to Kea 1.4.0-P1 or higher, available via https://www.isc.org/downloads."
}
],
"source": {
"discovery": "UNKNOWN"
},
"work_around": [
{
"lang": "en",
"value": "+ Monitoring and routinely restarting ISC Kea DHCPv4 and DHCPv6 services may be an effective mitigation for some production environments\n + Running a new build of Kea without any hook libraries that use the callout store is another option, though it may not be a viable option where the production environment is dependent on the other hooks that need to be omitted to avoid these symptoms. These hooks distributed by ISC do not use the callout store and are safe to use: Lease Commands, Stat Commands, Host Commands (a Kea Premium hook) and Subnet Commands (a subscriber-only hook provided to Kea support customers).\n + Reverting to Kea DHCP 1.3.0 may be possible for some production environments but because of differences in the database schema operators should check carefully before attempting rollback:\n - If using memfile storage entirely, there should not be any compatibility issues.\n - If using a database solution for hosts or leases, the 1.4.0 schema will be incompatible with ISC Kea 1.3.0; the database therefore must be restored from a pre-upgrade backup for this to be successful.\n - If you are unsure whether or not you can roll back to 1.3.0 without restoring a previous version of your database, you may send an e-mail to security-officer@isc.org describing your storage setup and we will advise."
}
]
}
}
},
"cveMetadata": {
"assignerOrgId": "404fd4d2-a609-4245-b543-2c944a302a22",
"assignerShortName": "isc",
"cveId": "CVE-2018-5739",
"datePublished": "2019-01-16T20:00:00Z",
"dateReserved": "2018-01-17T00:00:00",
"dateUpdated": "2024-09-17T02:11:49.386Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}