Action not permitted
Modal body text goes here.
Modal Title
Modal Body
Vulnerability from cleanstart
Package thingsboard version 4.3.1.3-r2 fixes 4 vulnerabilities: ghsa-j92g-9f8w-j867, CVE-2026-54291, ghsa-v422-hmwv-36x6, CVE-2026-12590
| URL | Type | |
|---|---|---|
{
"affected": [
{
"package": {
"ecosystem": "Alpine",
"name": "thingsboard"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.3.1.3-r2"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"4.3.1.3-r2"
]
}
],
"credits": [],
"database_specific": {},
"details": "Package thingsboard version 4.3.1.3-r2 fixes 4 vulnerabilities: ghsa-j92g-9f8w-j867, CVE-2026-54291, ghsa-v422-hmwv-36x6, CVE-2026-12590",
"id": "CLEANSTART-2026-DE16547",
"modified": "2026-08-14T05:57:04Z",
"published": "2026-08-13T12:10:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/thingsboard/thingsboard"
}
],
"related": [],
"schema_version": "1.7.3",
"summary": "Security fixes in thingsboard 4.3.1.3-r2",
"upstream": [
"ghsa-j92g-9f8w-j867",
"CVE-2026-54291",
"ghsa-v422-hmwv-36x6",
"CVE-2026-12590"
]
}
CVE-2026-12590 (GCVE-0-2026-12590)
Vulnerability from cvelistv5 – Published: 2026-07-09 10:21 – Updated: 2026-07-09 12:06- CWE-770 - Allocation of Resources Without Limits or Throttling
| Vendor | Product | Version | |
|---|---|---|---|
| body-parser | body-parser |
Affected:
0 , < 1.20.6
(semver)
Unaffected: 1.20.6 (semver) Affected: 2.0.0 , < 2.3.0 (semver) Unaffected: 2.3.0 (semver) |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-12590",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-07-09T12:05:36.853756Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-07-09T12:06:01.554Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"packageURL": "pkg:npm/body-parser",
"product": "body-parser",
"vendor": "body-parser",
"versions": [
{
"lessThan": "1.20.6",
"status": "affected",
"version": "0",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "1.20.6",
"versionType": "semver"
},
{
"lessThan": "2.3.0",
"status": "affected",
"version": "2.0.0",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "2.3.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Phillip9587"
},
{
"lang": "en",
"type": "remediation reviewer",
"value": "UlisesGascon"
},
{
"lang": "en",
"type": "analyst",
"value": "bjohansebas"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "Impact: In body-parser versions prior to 1.20.6 (1.x line) and 2.3.0 (2.x line), when the parser is configured with an invalid limit option value such as an unparseable string or NaN, bytes.parse returns null and the request body size check is silently skipped. Applications that rely on limit as their primary safeguard against oversized request bodies will accept arbitrarily large payloads, leading to excessive memory and CPU usage and denial of service. Patches: This issue is fixed in body-parser 1.20.6 and 2.3.0. After the fix, invalid limit values throw a clear error at parser construction time instead of silently disabling enforcement, while null and undefined continue to fall back to the default limit of 100kb. Workarounds: Validate the limit value before passing it to body-parser. For example, parse the value at startup and reject any configuration where the result is null or a non-finite number."
}
],
"value": "Impact: In body-parser versions prior to 1.20.6 (1.x line) and 2.3.0 (2.x line), when the parser is configured with an invalid limit option value such as an unparseable string or NaN, bytes.parse returns null and the request body size check is silently skipped. Applications that rely on limit as their primary safeguard against oversized request bodies will accept arbitrarily large payloads, leading to excessive memory and CPU usage and denial of service. Patches: This issue is fixed in body-parser 1.20.6 and 2.3.0. After the fix, invalid limit values throw a clear error at parser construction time instead of silently disabling enforcement, while null and undefined continue to fall back to the default limit of 100kb. Workarounds: Validate the limit value before passing it to body-parser. For example, parse the value at startup and reject any configuration where the result is null or a non-finite number."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 3.7,
"baseSeverity": "LOW",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-770",
"description": "CWE-770: Allocation of Resources Without Limits or Throttling",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-07-09T10:21:10.447Z",
"orgId": "ce714d77-add3-4f53-aff5-83d477b104bb",
"shortName": "openjs"
},
"references": [
{
"url": "https://github.com/expressjs/body-parser/security/advisories/GHSA-v422-hmwv-36x6"
},
{
"url": "https://cna.openjsf.org/security-advisories.html"
}
],
"title": "body-parser vulnerable to denial of service when invalid limit value silently disables size enforcement",
"x_generator": {
"engine": "cve-kit 1.0.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "ce714d77-add3-4f53-aff5-83d477b104bb",
"assignerShortName": "openjs",
"cveId": "CVE-2026-12590",
"datePublished": "2026-07-09T10:21:10.447Z",
"dateReserved": "2026-06-18T08:44:10.977Z",
"dateUpdated": "2026-07-09T12:06:01.554Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-54291 (GCVE-0-2026-54291)
Vulnerability from cvelistv5 – Published: 2026-07-06 18:55 – Updated: 2026-07-06 19:47| URL | Tags |
|---|---|
| https://github.com/pgjdbc/pgjdbc/security/advisor… | x_refsource_CONFIRM |
| https://github.com/pgjdbc/pgjdbc/commit/77df98e4e… | x_refsource_MISC |
| https://github.com/ongres/scram/releases/tag/3.3 | x_refsource_MISC |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-54291",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-07-06T19:47:12.248185Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-07-06T19:47:17.454Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "pgjdbc",
"vendor": "pgjdbc",
"versions": [
{
"status": "affected",
"version": "\u003e= 42.7.4, \u003c 42.7.12"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "pgjdbc is an open source postgresql JDBC Driver. In releases 42.7.4 through 42.7.11, channelBinding=require connections can be silently downgraded from SCRAM-SHA-256-PLUS with channel binding to plain SCRAM-SHA-256 without it, losing the man-in-the-middle protection the setting is meant to guarantee. An attacker who can intercept the TLS connection can trigger the downgrade with a certificate whose signature algorithm has no tls-server-end-point channel-binding hash, because the bundled com.ongres.scram:scram-client returns an empty byte array instead of failing and pgJDBC ScramAuthenticator checks only that the server advertised a PLUS mechanism, without rejecting the empty binding or checking that the negotiated mechanism uses channel binding. This issue is fixed in version 42.7.12."
}
],
"metrics": [
{
"cvssV4_0": {
"attackComplexity": "HIGH",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 8.2,
"baseSeverity": "HIGH",
"privilegesRequired": "NONE",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "LOW",
"userInteraction": "NONE",
"vectorString": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:L/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "HIGH"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-636",
"description": "CWE-636: Not Failing Securely (\u0027Failing Open\u0027)",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-757",
"description": "CWE-757: Selection of Less-Secure Algorithm During Negotiation (\u0027Algorithm Downgrade\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-07-06T18:55:01.675Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/pgjdbc/pgjdbc/security/advisories/GHSA-j92g-9f8w-j867",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/pgjdbc/pgjdbc/security/advisories/GHSA-j92g-9f8w-j867"
},
{
"name": "https://github.com/pgjdbc/pgjdbc/commit/77df98e4e66c12936ded3478a0954f6f580bad99",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/pgjdbc/pgjdbc/commit/77df98e4e66c12936ded3478a0954f6f580bad99"
},
{
"name": "https://github.com/ongres/scram/releases/tag/3.3",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/ongres/scram/releases/tag/3.3"
}
],
"source": {
"advisory": "GHSA-j92g-9f8w-j867",
"discovery": "UNKNOWN"
},
"title": "Silent channel-binding authentication downgrade via unsupported certificate algorithms"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-54291",
"datePublished": "2026-07-06T18:55:01.675Z",
"dateReserved": "2026-06-12T17:46:37.293Z",
"dateUpdated": "2026-07-06T19:47:17.454Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GHSA-J92G-9F8W-J867
Vulnerability from github – Published: 2026-07-21 17:47 – Updated: 2026-07-21 17:47Impact
channelBinding=require connections can be silently downgraded from SCRAM-SHA-256-PLUS (with channel binding) to plain SCRAM-SHA-256 (without it), losing the man-in-the-middle protection the setting is meant to guarantee. An attacker who can intercept the TLS connection triggers the downgrade with a certificate whose signature algorithm has no tls-server-end-point channel-binding hash. Examples are Ed25519, Ed448, and post-quantum algorithms.
Two issues combine in releases 42.7.4 through 42.7.11:
- The bundled
com.ongres.scram:scram-client(3.1 or 3.2) returns an empty byte array instead of failing when it cannot derive the binding hash for such a certificate. This is the library issue tracked as GHSA-p9jg-fcr6-3mhf. - pgJDBC does not enforce
channelBinding=requirewhere it matters.ScramAuthenticatorchecks only that the server advertised a-PLUSmechanism; it neither rejects the empty binding nor checks that the negotiated mechanism uses channel binding. The connection therefore downgrades silently, and would do so even against a fixedscram-client, because the missing enforcement is in pgJDBC's own code.
Only connections that set channelBinding=require are affected. Under the default prefer policy, and under allow or disable, falling back to plain SCRAM is the documented behaviour. Releases before 42.7.4 are unaffected, because they do not support channel binding.
Patches
Fixed in pgJDBC 42.7.12. pgJDBC now enforces channel binding in its own code, independently of the scram-client version:
- Under
channelBinding=require, it fails the connection when no channel-binding data can be extracted from the server certificate, instead of passing an empty value to the SCRAM client. The error names the certificate signature algorithm. - After negotiation, it requires the selected mechanism to use channel binding (a
-PLUSmechanism) wheneverchannelBinding=requireis set, regardless of how negotiation resolved.
Upgrade to 42.7.12 or later.
Workarounds
No pgJDBC setting restores channel-binding enforcement on an affected release; upgrading is the fix.
If you cannot upgrade immediately, verify the server certificate at the TLS layer so that a man-in-the-middle cannot present a substitute certificate. Set sslmode=verify-full with a truststore that contains only your server's CA. This defence is independent of channel binding and blocks the same attacker. Connections that rely on channelBinding=require in place of certificate verification have no equivalent workaround and should upgrade.
References
- GHSA-p9jg-fcr6-3mhf — the related
com.ongres.scram:scram-clientissue (root cause of the empty channel-binding value). scram-client3.3 release (library fix): https://github.com/ongres/scram/releases/tag/3.3- pgJDBC fix in 42.7.12: commit
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.postgresql:postgresql"
},
"ranges": [
{
"events": [
{
"introduced": "42.7.4"
},
{
"fixed": "42.7.12"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54291"
],
"database_specific": {
"cwe_ids": [
"CWE-636",
"CWE-757"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-21T17:47:39Z",
"nvd_published_at": "2026-07-06T19:17:08Z",
"severity": "HIGH"
},
"details": "### Impact\n\n`channelBinding=require` connections can be silently downgraded from `SCRAM-SHA-256-PLUS` (with channel binding) to plain `SCRAM-SHA-256` (without it), losing the man-in-the-middle protection the setting is meant to guarantee. An attacker who can intercept the TLS connection triggers the downgrade with a certificate whose signature algorithm has no `tls-server-end-point` channel-binding hash. Examples are `Ed25519`, `Ed448`, and post-quantum algorithms.\n\nTwo issues combine in releases 42.7.4 through 42.7.11:\n\n1. The bundled `com.ongres.scram:scram-client` (3.1 or 3.2) returns an empty byte array instead of failing when it cannot derive the binding hash for such a certificate. This is the library issue tracked as [GHSA-p9jg-fcr6-3mhf](https://github.com/ongres/scram/security/advisories/GHSA-p9jg-fcr6-3mhf).\n2. pgJDBC does not enforce `channelBinding=require` where it matters. `ScramAuthenticator` checks only that the server *advertised* a `-PLUS` mechanism; it neither rejects the empty binding nor checks that the *negotiated* mechanism uses channel binding. The connection therefore downgrades silently, and would do so even against a fixed `scram-client`, because the missing enforcement is in pgJDBC\u0027s own code.\n\nOnly connections that set `channelBinding=require` are affected. Under the default `prefer` policy, and under `allow` or `disable`, falling back to plain SCRAM is the documented behaviour. Releases before 42.7.4 are unaffected, because they do not support channel binding.\n\n### Patches\n\nFixed in pgJDBC 42.7.12. pgJDBC now enforces channel binding in its own code, independently of the `scram-client` version:\n\n- Under `channelBinding=require`, it fails the connection when no channel-binding data can be extracted from the server certificate, instead of passing an empty value to the SCRAM client. The error names the certificate signature algorithm.\n- After negotiation, it requires the selected mechanism to use channel binding (a `-PLUS` mechanism) whenever `channelBinding=require` is set, regardless of how negotiation resolved.\n\nUpgrade to 42.7.12 or later.\n\n### Workarounds\n\nNo pgJDBC setting restores channel-binding enforcement on an affected release; upgrading is the fix.\n\nIf you cannot upgrade immediately, verify the server certificate at the TLS layer so that a man-in-the-middle cannot present a substitute certificate. Set `sslmode=verify-full` with a truststore that contains only your server\u0027s CA. This defence is independent of channel binding and blocks the same attacker. Connections that rely on `channelBinding=require` in place of certificate verification have no equivalent workaround and should upgrade.\n\n### References\n\n- [GHSA-p9jg-fcr6-3mhf](https://github.com/ongres/scram/security/advisories/GHSA-p9jg-fcr6-3mhf) \u2014 the related `com.ongres.scram:scram-client` issue (root cause of the empty channel-binding value).\n- `scram-client` 3.3 release (library fix): https://github.com/ongres/scram/releases/tag/3.3\n- pgJDBC fix in 42.7.12: [commit](https://github.com/pgjdbc/pgjdbc/commit/77df98e4e66c12936ded3478a0954f6f580bad99)",
"id": "GHSA-j92g-9f8w-j867",
"modified": "2026-07-21T17:47:39Z",
"published": "2026-07-21T17:47:39Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pgjdbc/pgjdbc/security/advisories/GHSA-j92g-9f8w-j867"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54291"
},
{
"type": "WEB",
"url": "https://github.com/pgjdbc/pgjdbc/commit/77df98e4e66c12936ded3478a0954f6f580bad99"
},
{
"type": "WEB",
"url": "https://github.com/ongres/scram/releases/tag/3.3"
},
{
"type": "PACKAGE",
"url": "https://github.com/pgjdbc/pgjdbc"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "PostgreSQL JDBC Driver: Silent channel-binding authentication downgrade via unsupported certificate algorithms"
}
GHSA-V422-HMWV-36X6
Vulnerability from github – Published: 2026-07-20 23:23 – Updated: 2026-07-20 23:23Impact
When body-parser is configured with an invalid limit option value, such as an unparseable string or NaN, bytes.parse() returns null and the request body size check is silently skipped. Applications that rely on limit as their primary safeguard against oversized request bodies will accept arbitrarily large payloads, leading to excessive memory and CPU usage and denial of service.
This issue affects applications that pass a programmatically computed or user-configurable value to the limit option without validating it first.
Patches
This issue is fixed in body-parser@2.3.0 and body-parser@1.20.6 via #698. After the fix, invalid limit values throw a clear error at parser construction time instead of silently disabling enforcement. null and undefined continue to fall back to the default limit (100kb).
Workarounds
Validate limit before passing it to body-parser. For example, parse the value with bytes.parse() at startup and reject any configuration where it returns null or a non-finite number.
References
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "body-parser"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.20.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "body-parser"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.3.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-12590"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-20T23:23:26Z",
"nvd_published_at": "2026-07-09T11:16:24Z",
"severity": "LOW"
},
"details": "### Impact\n\nWhen body-parser is configured with an invalid `limit` option value, such as an unparseable string or `NaN`, `bytes.parse()` returns `null` and the request body size check is silently skipped. Applications that rely on `limit` as their primary safeguard against oversized request bodies will accept arbitrarily large payloads, leading to excessive memory and CPU usage and denial of service.\n\nThis issue affects applications that pass a programmatically computed or user-configurable value to the `limit` option without validating it first.\n\n### Patches\n\nThis issue is fixed in [body-parser@2.3.0](https://github.com/expressjs/body-parser/releases/tag/v2.3.0) and [body-parser@1.20.6](https://github.com/expressjs/body-parser/releases/tag/v1.20.6) via [#698](https://github.com/expressjs/body-parser/pull/698). After the fix, invalid `limit` values throw a clear error at parser construction time instead of silently disabling enforcement. `null` and `undefined` continue to fall back to the default limit (`100kb`).\n\n### Workarounds\n\nValidate `limit` before passing it to body-parser. For example, parse the value with [`bytes.parse()`](https://github.com/visionmedia/bytes.js) at startup and reject any configuration where it returns `null` or a non-finite number.\n\n### References\n\n- [#698](https://github.com/expressjs/body-parser/pull/698): fix PR\n- [bytes.js](https://github.com/visionmedia/bytes.js): limit parser",
"id": "GHSA-v422-hmwv-36x6",
"modified": "2026-07-20T23:23:26Z",
"published": "2026-07-20T23:23:26Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/expressjs/body-parser/security/advisories/GHSA-v422-hmwv-36x6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-12590"
},
{
"type": "WEB",
"url": "https://github.com/expressjs/body-parser/pull/698"
},
{
"type": "WEB",
"url": "https://github.com/expressjs/body-parser/pull/741"
},
{
"type": "WEB",
"url": "https://github.com/expressjs/body-parser/commit/2322e111cc321413ec2b7b76d01be533d3de9d7d"
},
{
"type": "WEB",
"url": "https://github.com/expressjs/body-parser/commit/3492672eee593d5c158f239b6e9115498a5dbeac"
},
{
"type": "WEB",
"url": "https://cna.openjsf.org/security-advisories.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/expressjs/body-parser"
},
{
"type": "WEB",
"url": "https://github.com/expressjs/body-parser/releases/tag/1.20.6"
},
{
"type": "WEB",
"url": "https://github.com/expressjs/body-parser/releases/tag/v2.3.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "body-parser vulnerable to denial of service when invalid limit value silently disables size enforcement"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.