From cd39538e9fc2daccdcf1f5bb321d9375c1d9ecc6 Mon Sep 17 00:00:00 2001 From: "advisory-database[bot]" <45398580+advisory-database[bot]@users.noreply.github.com> Date: Wed, 9 Apr 2025 20:01:05 +0000 Subject: [PATCH] Publish Advisories GHSA-47xc-9rr2-q7p4 GHSA-2qph-qpvm-2qf7 GHSA-32jq-mv89-5rx7 GHSA-wx8q-4gm9-rj2g GHSA-p3fp-8748-vqfq --- .../2022/10/GHSA-47xc-9rr2-q7p4/GHSA-47xc-9rr2-q7p4.json | 8 ++++++-- .../2024/03/GHSA-2qph-qpvm-2qf7/GHSA-2qph-qpvm-2qf7.json | 2 +- .../2024/03/GHSA-32jq-mv89-5rx7/GHSA-32jq-mv89-5rx7.json | 4 ++-- .../2024/03/GHSA-wx8q-4gm9-rj2g/GHSA-wx8q-4gm9-rj2g.json | 2 +- .../2025/03/GHSA-p3fp-8748-vqfq/GHSA-p3fp-8748-vqfq.json | 6 +++++- 5 files changed, 15 insertions(+), 7 deletions(-) diff --git a/advisories/github-reviewed/2022/10/GHSA-47xc-9rr2-q7p4/GHSA-47xc-9rr2-q7p4.json b/advisories/github-reviewed/2022/10/GHSA-47xc-9rr2-q7p4/GHSA-47xc-9rr2-q7p4.json index a481cd68753..8e9bf46e90f 100644 --- a/advisories/github-reviewed/2022/10/GHSA-47xc-9rr2-q7p4/GHSA-47xc-9rr2-q7p4.json +++ b/advisories/github-reviewed/2022/10/GHSA-47xc-9rr2-q7p4/GHSA-47xc-9rr2-q7p4.json @@ -1,13 +1,13 @@ { "schema_version": "1.4.0", "id": "GHSA-47xc-9rr2-q7p4", - "modified": "2023-06-27T21:56:04Z", + "modified": "2025-04-09T19:59:25Z", "published": "2022-10-25T19:56:51Z", "aliases": [ "CVE-2022-39327" ], "summary": "Improper Control of Generation of Code ('Code Injection') in Azure CLI", - "details": "# Description\n\nIn versions previous to 2.40.0, Azure CLI contains a vulnerability for potential code injection. Critical scenarios are where a hosting machine runs an Azure CLI command where parameter values have been provided by an external source. \n\nFor example: Application X is a web application with a feature that allows users to create Secrets in an Azure KeyVault. Instead of constructing API calls based on user input, Application X uses Azure CLI commands to create the secrets. Application X has input fields presented to the user and the Azure CLI command parameter values are filled based on the user input fields. This input, when formed correctly, could potentially be run as system commands. Below is an example of the resulting Azure CLI command run on the web app's hosting machine. \n\n```bash\naz keyvault secret set --vault-name SomeVault --name foobar --value \"abc123|whoami\"\n```\n\nThe above command could potentially run the `whoami` command on the hosting machine.\n\nInteractive, in-terminal use and automation/pipeline scenarios have not been identified as critical risk scenarios.\n\n## Code injection prerequisites\n\nThe vulnerability is only applicable when the Azure CLI command is run on a Windows machine **_and_** with any version of PowerShell **_and_**when the parameter value contains the `&` or `|` symbols. If any of these prerequisites are not met, this vulnerability is not applicable.\n\n### 1. The command has to be run on Windows\n\nThe Azure CLI has an entry script that, when run on Windows, calls cmd.exe to then call Python. This leads into the next prerequisite.\n\n### 2. The command has to be executed by PowerShell.\n\nPowerShell has input parsing designs that strip out the quotation marks of input with the expectation that it will be taken as a string. When used in a PowerShell environment, the command is input like the above command. However, when it passes through PowerShell into cmd.exe, it looks like the following. \n\n```powershell\naz keyvault secret set --vault-name SomeVault --name foobar --value abc123|whoami\n```\n\nThis leads to the 3rd prerequisite as it won’t just try to run any parameter value as a command. \n\n### 3. The parameter value has to contain a `&` or `|` symbols\n\nIn cmd.exe, the `&` and `|` symbols invoke command execution. When a string containing this symbols is passed directly to cmd.exe, quotes are kept and command execution is invoked. However, When a string is passed into PowerShell, the quotes are stripped and passed into cmd.exe making it open to execution.\n\nSo, in the `keyvault` example above, the `abc123` portion of the value will be accepted correctly but the value after the `|` symbol will be interpreted as a command. \n\n# Impact\n\n## Code injection\n\nAs mentioned in the above scenario where the value is being provided by and outside source to run an Azure CLI command, system commands or even scripts could be run on a hosting machine. \n\n# Patches\n\nUpgrade to Azure CLI 2.40.0 or greater. \n\nAs of Azure CLI 2.40.0, a new .ps1 entry script is used as the entry point to call Python rather than cmd.exe. This removes the opportunity for cmd.exe to interpret input as a command invocation. Using this approach has introduced new issues however that you can read about in the \"More information\" section.\n\nUpgrade to 2.41.0 or greater and manually call the azps.ps1 entry script in identified critical scenarios.\n\nIn Azure CLI 2.41.0 we have [reverted back](https://github.com/Azure/azure-cli/pull/24015) to using the cmd.exe entry script as the default while keeping the azps.ps1 entry script for manual Azure CLI calls if users require it.\n\n```powershell\nC:\\Program Files (x86)\\Microsoft SDKs\\Azure\\CLI2\\wbin\\azps.ps1 keyvault secret set --vault-name SomeVault --name foobar --value \"abc123|whoami\"\n```\n\n## More information\n\n### PowerShell Parsing with Azure CLI\n\nPowerShell’s input parsing design has caused regressions and issues in Azure CLI’s behavior resulting in broken scripts and pipelines. Below are the known issues and links to GitHub issues. This should not be taken as a complete list since these are **_only the reported_** issues. Users should verify command effectiveness before use in production environments.\n\n1. [PowerShell arrays can't be passed to Azure CLI](https://github.com/Azure/azure-cli/issues/23797)\n2. [Argument passthrough token (`--`) doesn't work with Azure CLI in PowerShell](https://github.com/Azure/azure-cli/issues/24034)\n3. [Stop parsing token (`--%`) no longer works with Azure CLI in PowerShell](https://github.com/Azure/azure-cli/issues/24114)\n4. [stdin passing is interrupted for Azure CLI in PowerShell](https://github.com/Azure/azure-cli/issues/2388)\n5. [Azure CLI returns 0 when failing in PowerShell](https://github.com/Azure/azure-cli/issues/23880)\n6. [Azure CLI can no longer be invoked by `Start-Process`](https://github.com/Azure/azure-cli/pull/24015)\n\nTo avoid these breaking changes, in Azure CLI 2.41.0 we have [reverted back](https://github.com/Azure/azure-cli/pull/24015) to using the cmd.exe entry script as the default while keeping the azps.ps1 entry script for manual Azure CLI calls if users require it.\n\n> 🗒️ The .ps1 entry script is only required for similarly identified scenarios like the example above. Interactive use and automation scenarios have not been identified as high risk.\n\nIf the azps.ps1 script is needed, you can call it like this: \n\n```powershell\nC:\\Program Files (x86)\\Microsoft SDKs\\Azure\\CLI2\\wbin\\azps.ps1 vm create\n```\n\nIf you have any questions or comments about this advisory:\n* Open an issue in [Azure CLI GitHub repo](https://github.com/Azure/azure-cli)\n* Email us at [AzPyCLI@microsoft.com](mailto:AzPyCLI@microsoft.com)\n", + "details": "# Description\n\nIn versions previous to 2.40.0, Azure CLI contains a vulnerability for potential code injection. Critical scenarios are where a hosting machine runs an Azure CLI command where parameter values have been provided by an external source. \n\nFor example: Application X is a web application with a feature that allows users to create Secrets in an Azure KeyVault. Instead of constructing API calls based on user input, Application X uses Azure CLI commands to create the secrets. Application X has input fields presented to the user and the Azure CLI command parameter values are filled based on the user input fields. This input, when formed correctly, could potentially be run as system commands. Below is an example of the resulting Azure CLI command run on the web app's hosting machine. \n\n```bash\naz keyvault secret set --vault-name SomeVault --name foobar --value \"abc123|whoami\"\n```\n\nThe above command could potentially run the `whoami` command on the hosting machine.\n\nInteractive, in-terminal use and automation/pipeline scenarios have not been identified as critical risk scenarios.\n\n## Code injection prerequisites\n\nThe vulnerability is only applicable when the Azure CLI command is run on a Windows machine **_and_** with any version of PowerShell **_and_**when the parameter value contains the `&` or `|` symbols. If any of these prerequisites are not met, this vulnerability is not applicable.\n\n### 1. The command has to be run on Windows\n\nThe Azure CLI has an entry script that, when run on Windows, calls cmd.exe to then call Python. This leads into the next prerequisite.\n\n### 2. The command has to be executed by PowerShell.\n\nPowerShell has input parsing designs that strip out the quotation marks of input with the expectation that it will be taken as a string. When used in a PowerShell environment, the command is input like the above command. However, when it passes through PowerShell into cmd.exe, it looks like the following. \n\n```powershell\naz keyvault secret set --vault-name SomeVault --name foobar --value abc123|whoami\n```\n\nThis leads to the 3rd prerequisite as it won’t just try to run any parameter value as a command. \n\n### 3. The parameter value has to contain a `&` or `|` symbols\n\nIn cmd.exe, the `&` and `|` symbols invoke command execution. When a string containing this symbols is passed directly to cmd.exe, quotes are kept and command execution is invoked. However, When a string is passed into PowerShell, the quotes are stripped and passed into cmd.exe making it open to execution.\n\nSo, in the `keyvault` example above, the `abc123` portion of the value will be accepted correctly but the value after the `|` symbol will be interpreted as a command. \n\n# Impact\n\n## Code injection\n\nAs mentioned in the above scenario where the value is being provided by and outside source to run an Azure CLI command, system commands or even scripts could be run on a hosting machine. \n\n# Patches\n\nUpgrade to Azure CLI 2.40.0 or greater. \n\nAs of Azure CLI 2.40.0, a new .ps1 entry script is used as the entry point to call Python rather than cmd.exe. This removes the opportunity for cmd.exe to interpret input as a command invocation. Using this approach has introduced new issues however that you can read about in the \"More information\" section.\n\nUpgrade to 2.41.0 or greater and manually call the azps.ps1 entry script in identified critical scenarios.\n\nIn Azure CLI 2.41.0 we have [reverted back](https://github.com/Azure/azure-cli/pull/24015) to using the cmd.exe entry script as the default while keeping the azps.ps1 entry script for manual Azure CLI calls if users require it.\n\n```powershell\nC:\\Program Files (x86)\\Microsoft SDKs\\Azure\\CLI2\\wbin\\azps.ps1 keyvault secret set --vault-name SomeVault --name foobar --value \"abc123|whoami\"\n```\n\n## More information\n\n### PowerShell Parsing with Azure CLI\n\nPowerShell’s input parsing design has caused regressions and issues in Azure CLI’s behavior resulting in broken scripts and pipelines. Below are the known issues and links to GitHub issues. This should not be taken as a complete list since these are **_only the reported_** issues. Users should verify command effectiveness before use in production environments.\n\n1. [PowerShell arrays can't be passed to Azure CLI](https://github.com/Azure/azure-cli/issues/23797)\n2. [Argument passthrough token (`--`) doesn't work with Azure CLI in PowerShell](https://github.com/Azure/azure-cli/issues/24034)\n3. [Stop parsing token (`--%`) no longer works with Azure CLI in PowerShell](https://github.com/Azure/azure-cli/issues/24114)\n4. [stdin passing is interrupted for Azure CLI in PowerShell](https://github.com/Azure/azure-cli/issues/2388)\n5. [Azure CLI returns 0 when failing in PowerShell](https://github.com/Azure/azure-cli/issues/23880)\n6. [Azure CLI can no longer be invoked by `Start-Process`](https://github.com/Azure/azure-cli/pull/24015)\n\nTo avoid these breaking changes, in Azure CLI 2.41.0 we have [reverted back](https://github.com/Azure/azure-cli/pull/24015) to using the cmd.exe entry script as the default while keeping the azps.ps1 entry script for manual Azure CLI calls if users require it.\n\n> 🗒️ The .ps1 entry script is only required for similarly identified scenarios like the example above. Interactive use and automation scenarios have not been identified as high risk.\n\nIf the azps.ps1 script is needed, you can call it like this: \n\n```powershell\nC:\\Program Files (x86)\\Microsoft SDKs\\Azure\\CLI2\\wbin\\azps.ps1 vm create\n```\n\nIf you have any questions or comments about this advisory:\n* Open an issue in [Azure CLI GitHub repo](https://github.com/Azure/azure-cli)\n* Email us at [AzPyCLI@microsoft.com](mailto:AzPyCLI@microsoft.com)", "severity": [ { "type": "CVSS_V3", @@ -55,6 +55,10 @@ { "type": "PACKAGE", "url": "https://github.com/Azure/azure-cli" + }, + { + "type": "WEB", + "url": "https://github.com/pypa/advisory-database/tree/main/vulns/azure-cli/PYSEC-2022-43177.yaml" } ], "database_specific": { diff --git a/advisories/github-reviewed/2024/03/GHSA-2qph-qpvm-2qf7/GHSA-2qph-qpvm-2qf7.json b/advisories/github-reviewed/2024/03/GHSA-2qph-qpvm-2qf7/GHSA-2qph-qpvm-2qf7.json index b642c2a057a..62ca7421e43 100644 --- a/advisories/github-reviewed/2024/03/GHSA-2qph-qpvm-2qf7/GHSA-2qph-qpvm-2qf7.json +++ b/advisories/github-reviewed/2024/03/GHSA-2qph-qpvm-2qf7/GHSA-2qph-qpvm-2qf7.json @@ -1,7 +1,7 @@ { "schema_version": "1.4.0", "id": "GHSA-2qph-qpvm-2qf7", - "modified": "2024-05-20T15:29:52Z", + "modified": "2025-04-09T19:58:53Z", "published": "2024-03-15T19:57:22Z", "aliases": [ "CVE-2024-28854" diff --git a/advisories/github-reviewed/2024/03/GHSA-32jq-mv89-5rx7/GHSA-32jq-mv89-5rx7.json b/advisories/github-reviewed/2024/03/GHSA-32jq-mv89-5rx7/GHSA-32jq-mv89-5rx7.json index e9c5cde7095..f64ac94c8d7 100644 --- a/advisories/github-reviewed/2024/03/GHSA-32jq-mv89-5rx7/GHSA-32jq-mv89-5rx7.json +++ b/advisories/github-reviewed/2024/03/GHSA-32jq-mv89-5rx7/GHSA-32jq-mv89-5rx7.json @@ -1,13 +1,13 @@ { "schema_version": "1.4.0", "id": "GHSA-32jq-mv89-5rx7", - "modified": "2024-03-18T18:33:15Z", + "modified": "2025-04-09T19:58:40Z", "published": "2024-03-15T19:20:17Z", "aliases": [ "CVE-2024-28252" ], "summary": "CoreWCF NetFraming based services can leave connections open when they should be closed", - "details": "### Impact\nIf you have a NetFraming based CoreWCF service, extra system resources could be consumed by connections being left established instead of closing or aborting them. There are two scenarios when this can happen. When a client established a connection to the service and sends no data, the service will wait indefinitely for the client to initiate the NetFraming session handshake. Additionally, once a client has established a session, if the client doesn't send any requests for the period of time configured in the binding ReceiveTimeout, the connection is not properly closed as part of the session being aborted. \nThe bindings affected by this behavior are NetTcpBinding, NetNamedPipeBinding, and UnixDomainSocketBinding. Only NetTcpBinding has the ability to accept non local connections.\n\n### Patches\nThe currently supported versions of CoreWCF are v1.4.x and v1.5.x. The fix can be found in v1.4.2 and v1.5.2 of the CoreWCF packages.\n\n### Workarounds\nThere are no workarounds.\n\n### References\nhttps://github.com/CoreWCF/CoreWCF/issues/1345\n", + "details": "### Impact\nIf you have a NetFraming based CoreWCF service, extra system resources could be consumed by connections being left established instead of closing or aborting them. There are two scenarios when this can happen. When a client established a connection to the service and sends no data, the service will wait indefinitely for the client to initiate the NetFraming session handshake. Additionally, once a client has established a session, if the client doesn't send any requests for the period of time configured in the binding ReceiveTimeout, the connection is not properly closed as part of the session being aborted. \nThe bindings affected by this behavior are NetTcpBinding, NetNamedPipeBinding, and UnixDomainSocketBinding. Only NetTcpBinding has the ability to accept non local connections.\n\n### Patches\nThe currently supported versions of CoreWCF are v1.4.x and v1.5.x. The fix can be found in v1.4.2 and v1.5.2 of the CoreWCF packages.\n\n### Workarounds\nThere are no workarounds.\n\n### References\nhttps://github.com/CoreWCF/CoreWCF/issues/1345", "severity": [ { "type": "CVSS_V3", diff --git a/advisories/github-reviewed/2024/03/GHSA-wx8q-4gm9-rj2g/GHSA-wx8q-4gm9-rj2g.json b/advisories/github-reviewed/2024/03/GHSA-wx8q-4gm9-rj2g/GHSA-wx8q-4gm9-rj2g.json index 113dce9911e..80e65b73b8a 100644 --- a/advisories/github-reviewed/2024/03/GHSA-wx8q-4gm9-rj2g/GHSA-wx8q-4gm9-rj2g.json +++ b/advisories/github-reviewed/2024/03/GHSA-wx8q-4gm9-rj2g/GHSA-wx8q-4gm9-rj2g.json @@ -1,7 +1,7 @@ { "schema_version": "1.4.0", "id": "GHSA-wx8q-4gm9-rj2g", - "modified": "2024-03-18T18:33:11Z", + "modified": "2025-04-09T19:58:59Z", "published": "2024-03-15T16:35:11Z", "aliases": [ "CVE-2023-51699" diff --git a/advisories/github-reviewed/2025/03/GHSA-p3fp-8748-vqfq/GHSA-p3fp-8748-vqfq.json b/advisories/github-reviewed/2025/03/GHSA-p3fp-8748-vqfq/GHSA-p3fp-8748-vqfq.json index 9d90cb041bd..b0d1295bbe1 100644 --- a/advisories/github-reviewed/2025/03/GHSA-p3fp-8748-vqfq/GHSA-p3fp-8748-vqfq.json +++ b/advisories/github-reviewed/2025/03/GHSA-p3fp-8748-vqfq/GHSA-p3fp-8748-vqfq.json @@ -1,7 +1,7 @@ { "schema_version": "1.4.0", "id": "GHSA-p3fp-8748-vqfq", - "modified": "2025-03-19T21:30:45Z", + "modified": "2025-04-09T20:00:24Z", "published": "2025-03-06T21:31:26Z", "aliases": [ "CVE-2025-26699" @@ -86,6 +86,10 @@ "type": "PACKAGE", "url": "https://github.com/django/django" }, + { + "type": "WEB", + "url": "https://github.com/pypa/advisory-database/tree/main/vulns/django/PYSEC-2025-13.yaml" + }, { "type": "WEB", "url": "https://groups.google.com/g/django-announce"