Vulnerability-Lookup

CVE-2026-81862 (GCVE-0-2026-81862)

Vulnerability from cvelistv5 – Published: 2026-09-29 09:59 – Updated: 2026-09-29 20:04

Title

Apache Airflow Teradata provider: Teradata transfer operators embed cloud storage credentials in SQL text, task logs and Teradata query logs

Summary

Apache Airflow's Teradata provider embedded cloud storage credentials directly into SQL statements. `S3ToTeradataOperator` and `AzureBlobStorageToTeradataOperator` interpolate the source bucket's credentials as plain string literals into the `CREATE MULTISET TABLE ... LOCATION` statement whenever the bucket is private and no `teradata_authorization_name` is configured — which is the default credential path for both operators. The statement is then logged and executed, so the credentials reach two places outside the operator's control. The two operators expose different credentials through different channels, and deployments should check both. `S3ToTeradataOperator` takes its values from `s3_hook.get_credentials()`, which under an instance profile or IRSA returns runtime AWS credentials that were never registered with Airflow's secrets masker — and the STS session token is runtime-generated and therefore unmasked even when an AWS connection is configured. Those credentials appear **in the Airflow task log**, readable by any user with log-view permission on the Dag. `AzureBlobStorageToTeradataOperator` takes its storage account key from the connection, so the masker usually redacts the task-log copy; its exposure is the Teradata side. **Both** operators write the credentials into Teradata's DBQL query logs and live monitoring views, where Airflow's masking never applies and the values persist for that system's log retention period. Affects deployments using either operator against a private bucket or container without a Teradata `AUTHORIZATION` object. Users are advised to upgrade to `apache-airflow-providers-teradata` `3.7.0` or later, which keeps the credential-bearing statement out of the Airflow task log. Upgrading does not remove the credentials from Teradata's query logs and monitoring views, which Airflow cannot redact: users should configure `teradata_authorization_name` with a Teradata `AUTHORIZATION` object so that credentials are never inlined, and should rotate any credentials previously used through the inline path.

Severity

6.5 (Medium)


                        
                          CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

SSVC

Exploitation: none Automatable: no Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-09-29 20:03 UTC

CWE

CWE-532 - Insertion of Sensitive Information into Log File

Assigner

apache mitre root Scorecard

References

3 references

URL	Tags
https://github.com/apache/airflow/pull/72176	patch
https://lists.apache.org/thread/0vfpoh6l8gz0dpbc9…	vendor-advisory
http://www.openwall.com/lists/oss-security/2026/0…

Impacted products

1 product

Vendor	Product	Version	CPE status
Apache Software Foundation	Apache Airflow Teradata provider	Affected: 0 , < 3.7.0 (semver)	guessed

Credits

Claude Security Scans Jarek Potiuk

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2026-09-29T11:08:13.811Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "http://www.openwall.com/lists/oss-security/2026/09/29/11"
          }
        ],
        "title": "CVE Program Container"
      },
      {
        "metrics": [
          {
            "cvssV3_1": {
              "attackComplexity": "LOW",
              "attackVector": "NETWORK",
              "availabilityImpact": "NONE",
              "baseScore": 6.5,
              "baseSeverity": "MEDIUM",
              "confidentialityImpact": "HIGH",
              "integrityImpact": "NONE",
              "privilegesRequired": "LOW",
              "scope": "UNCHANGED",
              "userInteraction": "NONE",
              "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
              "version": "3.1"
            }
          },
          {
            "other": {
              "content": {
                "id": "CVE-2026-81862",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-09-29T20:03:58.980033Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-09-29T20:04:41.683Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://pypi.python.org",
          "defaultStatus": "unaffected",
          "packageName": "apache-airflow-providers-teradata",
          "packageURL": "pkg:pypi/apache-airflow-providers-teradata",
          "product": "Apache Airflow Teradata provider",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThan": "3.7.0",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "tool",
          "value": "Claude Security Scans"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Jarek Potiuk"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "Apache Airflow\u0026#x27;s Teradata provider embedded cloud storage credentials directly into SQL statements. `S3ToTeradataOperator` and `AzureBlobStorageToTeradataOperator` interpolate the source bucket\u0026#x27;s credentials as plain string literals into the `CREATE MULTISET TABLE ... LOCATION` statement whenever the bucket is private and no `teradata_authorization_name` is configured \u2014 which is the default credential path for both operators. The statement is then logged and executed, so the credentials reach two places outside the operator\u0026#x27;s control.\u003cbr\u003e\u003cbr\u003eThe two operators expose different credentials through different channels, and deployments should check both. `S3ToTeradataOperator` takes its values from `s3_hook.get_credentials()`, which under an instance profile or IRSA returns runtime AWS credentials that were never registered with Airflow\u0026#x27;s secrets masker \u2014 and the STS session token is runtime-generated and therefore unmasked even when an AWS connection is configured. Those credentials appear **in the Airflow task log**, readable by any user with log-view permission on the Dag. `AzureBlobStorageToTeradataOperator` takes its storage account key from the connection, so the masker usually redacts the task-log copy; its exposure is the Teradata side. **Both** operators write the credentials into Teradata\u0026#x27;s DBQL query logs and live monitoring views, where Airflow\u0026#x27;s masking never applies and the values persist for that system\u0026#x27;s log retention period.\u003cbr\u003e\u003cbr\u003eAffects deployments using either operator against a private bucket or container without a Teradata `AUTHORIZATION` object. Users are advised to upgrade to `apache-airflow-providers-teradata` `3.7.0` or later, which keeps the credential-bearing statement out of the Airflow task log. Upgrading does not remove the credentials from Teradata\u0026#x27;s query logs and monitoring views, which Airflow cannot redact: users should configure `teradata_authorization_name` with a Teradata `AUTHORIZATION` object so that credentials are never inlined, and should rotate any credentials previously used through the inline path."
            }
          ],
          "value": "Apache Airflow\u0027s Teradata provider embedded cloud storage credentials directly into SQL statements. `S3ToTeradataOperator` and `AzureBlobStorageToTeradataOperator` interpolate the source bucket\u0027s credentials as plain string literals into the `CREATE MULTISET TABLE ... LOCATION` statement whenever the bucket is private and no `teradata_authorization_name` is configured \u2014 which is the default credential path for both operators. The statement is then logged and executed, so the credentials reach two places outside the operator\u0027s control.\n\nThe two operators expose different credentials through different channels, and deployments should check both. `S3ToTeradataOperator` takes its values from `s3_hook.get_credentials()`, which under an instance profile or IRSA returns runtime AWS credentials that were never registered with Airflow\u0027s secrets masker \u2014 and the STS session token is runtime-generated and therefore unmasked even when an AWS connection is configured. Those credentials appear **in the Airflow task log**, readable by any user with log-view permission on the Dag. `AzureBlobStorageToTeradataOperator` takes its storage account key from the connection, so the masker usually redacts the task-log copy; its exposure is the Teradata side. **Both** operators write the credentials into Teradata\u0027s DBQL query logs and live monitoring views, where Airflow\u0027s masking never applies and the values persist for that system\u0027s log retention period.\n\nAffects deployments using either operator against a private bucket or container without a Teradata `AUTHORIZATION` object. Users are advised to upgrade to `apache-airflow-providers-teradata` `3.7.0` or later, which keeps the credential-bearing statement out of the Airflow task log. Upgrading does not remove the credentials from Teradata\u0027s query logs and monitoring views, which Airflow cannot redact: users should configure `teradata_authorization_name` with a Teradata `AUTHORIZATION` object so that credentials are never inlined, and should rotate any credentials previously used through the inline path."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "moderate"
            },
            "type": "Textual description of severity"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-532",
              "description": "CWE-532: Insertion of Sensitive Information into Log File",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-29T09:59:35.774Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/apache/airflow/pull/72176"
        },
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://lists.apache.org/thread/0vfpoh6l8gz0dpbc9z50dmkc3z07o83l"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Apache Airflow Teradata provider: Teradata transfer operators embed cloud storage credentials in SQL text, task logs and Teradata query logs",
      "x_generator": {
        "engine": "airflow-s/generate_cve_json.py"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-81862",
    "datePublished": "2026-09-29T09:59:35.774Z",
    "dateReserved": "2026-08-27T16:50:11.575Z",
    "dateUpdated": "2026-09-29T20:04:41.683Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-81862",
      "date": "2026-09-30",
      "epss": "0.00276",
      "percentile": "0.18079"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "collectionURL": "https://pypi.python.org",
                "defaultStatus": "unaffected",
                "packageName": "apache-airflow-providers-teradata",
                "packageURL": "pkg:pypi/apache-airflow-providers-teradata",
                "product": "Apache Airflow Teradata provider",
                "vendor": "Apache Software Foundation",
                "versions": [
                  {
                    "lessThan": "3.7.0",
                    "status": "affected",
                    "version": "0",
                    "versionType": "semver"
                  }
                ]
              }
            ],
            "source": "security@apache.org"
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "Apache Airflow\u0027s Teradata provider embedded cloud storage credentials directly into SQL statements. `S3ToTeradataOperator` and `AzureBlobStorageToTeradataOperator` interpolate the source bucket\u0027s credentials as plain string literals into the `CREATE MULTISET TABLE ... LOCATION` statement whenever the bucket is private and no `teradata_authorization_name` is configured \u2014 which is the default credential path for both operators. The statement is then logged and executed, so the credentials reach two places outside the operator\u0027s control.\n\nThe two operators expose different credentials through different channels, and deployments should check both. `S3ToTeradataOperator` takes its values from `s3_hook.get_credentials()`, which under an instance profile or IRSA returns runtime AWS credentials that were never registered with Airflow\u0027s secrets masker \u2014 and the STS session token is runtime-generated and therefore unmasked even when an AWS connection is configured. Those credentials appear **in the Airflow task log**, readable by any user with log-view permission on the Dag. `AzureBlobStorageToTeradataOperator` takes its storage account key from the connection, so the masker usually redacts the task-log copy; its exposure is the Teradata side. **Both** operators write the credentials into Teradata\u0027s DBQL query logs and live monitoring views, where Airflow\u0027s masking never applies and the values persist for that system\u0027s log retention period.\n\nAffects deployments using either operator against a private bucket or container without a Teradata `AUTHORIZATION` object. Users are advised to upgrade to `apache-airflow-providers-teradata` `3.7.0` or later, which keeps the credential-bearing statement out of the Airflow task log. Upgrading does not remove the credentials from Teradata\u0027s query logs and monitoring views, which Airflow cannot redact: users should configure `teradata_authorization_name` with a Teradata `AUTHORIZATION` object so that credentials are never inlined, and should rotate any credentials previously used through the inline path."
          }
        ],
        "id": "CVE-2026-81862",
        "lastModified": "2026-09-29T21:19:31.700",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "NETWORK",
                "availabilityImpact": "NONE",
                "baseScore": 6.5,
                "baseSeverity": "MEDIUM",
                "confidentialityImpact": "HIGH",
                "integrityImpact": "NONE",
                "privilegesRequired": "LOW",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
                "version": "3.1"
              },
              "exploitabilityScore": 2.8,
              "impactScore": 3.6,
              "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "type": "Secondary"
            }
          ],
          "ssvcV203": [
            {
              "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "ssvcData": {
                "id": "CVE-2026-81862",
                "options": [
                  {
                    "exploitation": "none"
                  },
                  {
                    "automatable": "no"
                  },
                  {
                    "technicalImpact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-09-29T20:03:58.980033Z",
                "version": "2.0.3"
              }
            }
          ]
        },
        "published": "2026-09-29T10:17:12.367",
        "references": [
          {
            "source": "security@apache.org",
            "url": "https://github.com/apache/airflow/pull/72176"
          },
          {
            "source": "security@apache.org",
            "url": "https://lists.apache.org/thread/0vfpoh6l8gz0dpbc9z50dmkc3z07o83l"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "url": "http://www.openwall.com/lists/oss-security/2026/09/29/11"
          }
        ],
        "sourceIdentifier": "security@apache.org",
        "vulnStatus": "Awaiting Analysis",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-532"
              }
            ],
            "source": "security@apache.org",
            "type": "Secondary"
          }
        ]
      }
    }
  }
}

FKIE_CVE-2026-81862

Vulnerability from fkie_nvd - Published: 2026-09-29 10:17 - Updated: 2026-09-29 21:19

Severity

6.5 (Medium) - CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Summary

References

	URL	Tags
	security@apache.org	https://github.com/apache/airflow/pull/72176
	security@apache.org	https://lists.apache.org/thread/0vfpoh6l8gz0dpbc9z50dmkc3z07o83l
	af854a3a-2127-422b-91ae-364da2661108	http://www.openwall.com/lists/oss-security/2026/09/29/11

Impacted products

	Vendor	Product	Version

JSON

To clipboard

{
  "affected": [
    {
      "affectedData": [
        {
          "collectionURL": "https://pypi.python.org",
          "defaultStatus": "unaffected",
          "packageName": "apache-airflow-providers-teradata",
          "packageURL": "pkg:pypi/apache-airflow-providers-teradata",
          "product": "Apache Airflow Teradata provider",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThan": "3.7.0",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "source": "security@apache.org"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "Apache Airflow\u0027s Teradata provider embedded cloud storage credentials directly into SQL statements. `S3ToTeradataOperator` and `AzureBlobStorageToTeradataOperator` interpolate the source bucket\u0027s credentials as plain string literals into the `CREATE MULTISET TABLE ... LOCATION` statement whenever the bucket is private and no `teradata_authorization_name` is configured \u2014 which is the default credential path for both operators. The statement is then logged and executed, so the credentials reach two places outside the operator\u0027s control.\n\nThe two operators expose different credentials through different channels, and deployments should check both. `S3ToTeradataOperator` takes its values from `s3_hook.get_credentials()`, which under an instance profile or IRSA returns runtime AWS credentials that were never registered with Airflow\u0027s secrets masker \u2014 and the STS session token is runtime-generated and therefore unmasked even when an AWS connection is configured. Those credentials appear **in the Airflow task log**, readable by any user with log-view permission on the Dag. `AzureBlobStorageToTeradataOperator` takes its storage account key from the connection, so the masker usually redacts the task-log copy; its exposure is the Teradata side. **Both** operators write the credentials into Teradata\u0027s DBQL query logs and live monitoring views, where Airflow\u0027s masking never applies and the values persist for that system\u0027s log retention period.\n\nAffects deployments using either operator against a private bucket or container without a Teradata `AUTHORIZATION` object. Users are advised to upgrade to `apache-airflow-providers-teradata` `3.7.0` or later, which keeps the credential-bearing statement out of the Airflow task log. Upgrading does not remove the credentials from Teradata\u0027s query logs and monitoring views, which Airflow cannot redact: users should configure `teradata_authorization_name` with a Teradata `AUTHORIZATION` object so that credentials are never inlined, and should rotate any credentials previously used through the inline path."
    }
  ],
  "id": "CVE-2026-81862",
  "lastModified": "2026-09-29T21:19:31.700",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 6.5,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "NONE",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 2.8,
        "impactScore": 3.6,
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-81862",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-09-29T20:03:58.980033Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-09-29T10:17:12.367",
  "references": [
    {
      "source": "security@apache.org",
      "url": "https://github.com/apache/airflow/pull/72176"
    },
    {
      "source": "security@apache.org",
      "url": "https://lists.apache.org/thread/0vfpoh6l8gz0dpbc9z50dmkc3z07o83l"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "url": "http://www.openwall.com/lists/oss-security/2026/09/29/11"
    }
  ],
  "sourceIdentifier": "security@apache.org",
  "vulnStatus": "Awaiting Analysis",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-532"
        }
      ],
      "source": "security@apache.org",
      "type": "Secondary"
    }
  ]
}

GHSA-JCPW-3G4P-9HMJ

Vulnerability from github – Published: 2026-09-29 12:31 – Updated: 2026-09-29 21:33

Details

Apache Airflow's Teradata provider embedded cloud storage credentials directly into SQL statements. S3ToTeradataOperator and AzureBlobStorageToTeradataOperator interpolate the source bucket's credentials as plain string literals into the CREATE MULTISET TABLE ... LOCATION statement whenever the bucket is private and no teradata_authorization_name is configured — which is the default credential path for both operators. The statement is then logged and executed, so the credentials reach two places outside the operator's control.

The two operators expose different credentials through different channels, and deployments should check both. S3ToTeradataOperator takes its values from s3_hook.get_credentials(), which under an instance profile or IRSA returns runtime AWS credentials that were never registered with Airflow's secrets masker — and the STS session token is runtime-generated and therefore unmasked even when an AWS connection is configured. Those credentials appear in the Airflow task log, readable by any user with log-view permission on the Dag. AzureBlobStorageToTeradataOperator takes its storage account key from the connection, so the masker usually redacts the task-log copy; its exposure is the Teradata side. Both operators write the credentials into Teradata's DBQL query logs and live monitoring views, where Airflow's masking never applies and the values persist for that system's log retention period.

Affects deployments using either operator against a private bucket or container without a Teradata AUTHORIZATION object. Users are advised to upgrade to apache-airflow-providers-teradata 3.7.0 or later, which keeps the credential-bearing statement out of the Airflow task log. Upgrading does not remove the credentials from Teradata's query logs and monitoring views, which Airflow cannot redact: users should configure teradata_authorization_name with a Teradata AUTHORIZATION object so that credentials are never inlined, and should rotate any credentials previously used through the inline path.

Severity

6.5 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-81862"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-29T10:17:12Z",
    "severity": "MODERATE"
  },
  "details": "Apache Airflow\u0027s Teradata provider embedded cloud storage credentials directly into SQL statements. `S3ToTeradataOperator` and `AzureBlobStorageToTeradataOperator` interpolate the source bucket\u0027s credentials as plain string literals into the `CREATE MULTISET TABLE ... LOCATION` statement whenever the bucket is private and no `teradata_authorization_name` is configured \u2014 which is the default credential path for both operators. The statement is then logged and executed, so the credentials reach two places outside the operator\u0027s control.\n\nThe two operators expose different credentials through different channels, and deployments should check both. `S3ToTeradataOperator` takes its values from `s3_hook.get_credentials()`, which under an instance profile or IRSA returns runtime AWS credentials that were never registered with Airflow\u0027s secrets masker \u2014 and the STS session token is runtime-generated and therefore unmasked even when an AWS connection is configured. Those credentials appear **in the Airflow task log**, readable by any user with log-view permission on the Dag. `AzureBlobStorageToTeradataOperator` takes its storage account key from the connection, so the masker usually redacts the task-log copy; its exposure is the Teradata side. **Both** operators write the credentials into Teradata\u0027s DBQL query logs and live monitoring views, where Airflow\u0027s masking never applies and the values persist for that system\u0027s log retention period.\n\nAffects deployments using either operator against a private bucket or container without a Teradata `AUTHORIZATION` object. Users are advised to upgrade to `apache-airflow-providers-teradata` `3.7.0` or later, which keeps the credential-bearing statement out of the Airflow task log. Upgrading does not remove the credentials from Teradata\u0027s query logs and monitoring views, which Airflow cannot redact: users should configure `teradata_authorization_name` with a Teradata `AUTHORIZATION` object so that credentials are never inlined, and should rotate any credentials previously used through the inline path.",
  "id": "GHSA-jcpw-3g4p-9hmj",
  "modified": "2026-09-29T21:33:09Z",
  "published": "2026-09-29T12:31:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-81862"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/airflow/pull/72176"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/0vfpoh6l8gz0dpbc9z50dmkc3z07o83l"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/09/29/11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

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 MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
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.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

CVE-2026-81862 (GCVE-0-2026-81862)

FKIE_CVE-2026-81862

GHSA-JCPW-3G4P-9HMJ

Tags

Sightings

Nomenclature

Related by attack behaviour