deployment templates leak value of _artifactsLocationSasToken

Alexander Clouter 21 Reputation points
2026-06-19T08:01:05.38+00:00

There is an issue affecting both Service Catalog and Marketplace offers where the value of _artifactsLocationSasToken is leaked.

I have been following the instructions for a few years regarding referencing linked templates and artifacts and around May 2025 I noticed that for Service Catalog deployments this value was leaked and then around February 2026 it started to affect Marketplace offers.

The leak does not appear in the deployment for the resource group containing the managed application resource but if you look at the input parameters for the main deployment template of the managed resource group you can see that the value of _artifactsLocationSasToken is empty (as it is marked as a secret) but it is there in plaintext appended to the clear text value of _artifactsLocation.

Some screenshots of this behaviour from a Service Catalog deployment made this week, this one is of the managed application resource so it is okay (correlation ID 30c01d17-0f68-4f47-a61d-633ee2cc5df9):
<PII Removed>

Here is the main parent template for the managed resource group which is affected (correlation ID f673ff36-692f-4eb9-8f8d-361e5df9401f):

<PII Removed>
You can observe the same issue for Marketplace offers too.

I reported this to MSRC back in Feb 2026 (VULN-174073) but their initial response was this was not an important issue as the data is only leaked by someone with deployment rights which I countered with:

  • Service Catalog deployments are often created by IT teams for use by other groups in an organisation and it may be undesirable to leak even same-tenant information
  • Marketplace offer deployments are publisher owned content so leaking this cross-tenant information is very undesirable

These templates can contain secrets (as hardcoded variables) as the recommended "use KeyVault references" overlooks the very difficult problem of how to import a publisher provided secret into the Key Vault without making that secret public.

Azure thought they had a fix for this deployed at the start of April but it the issue remained.

Now I have been instructed to contact Microsoft Support for information regarding the progress, but as they do not cover Azure here seems to be the only outlet available to me to find out progress of the issue:

User's image

Can the product engineering team(s) chime in on the progress here for me? This issue is important to me as a publisher on the Marketplace as it leaks my Intellectual Property so I am keen to see this resolved; in particularly so as the fix looks to be a straight forward case of amending the original mistake of appending _artifactsLocationSasToken to _artifactsLocation and place it in its correct input parameter field.

Azure Managed Applications
Azure Managed Applications

An Azure service that enables managed service providers, independent software vendors, and enterprise IT teams to deliver turnkey solutions through the Azure Marketplace or service catalog.


1 answer

Sort by: Most helpful
  1. Sina Salam 31,456 Reputation points Volunteer Moderator
    2026-06-30T13:52:29.3833333+00:00

    Hello Alexander Clouter,

    Welcome to the Microsoft Q&A and thank you for posting your questions here.

    I understand that your deployment templates leak value of _artifactsLocationSasToken.

    The issue is not caused by the normal ARM template pattern if your template defines _artifactsLocation as a plain base URI and _artifactsLocationSasToken as a separate securestring. The pattern requires _artifactsLocationSasToken to remain separate from _artifactsLocation, and the token should only be combined with the artifact URI when referencing nested templates, scripts, or other artifacts. - https://learn.microsoft.com/en-us/azure/azure-resource-manager/managed-applications/artifacts-location, https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/parameters

    You will need to validate that your mainTemplate.json follows the official pattern below:

    "parameters": {
      "_artifactsLocation": {
        "type": "string",
        "defaultValue": "[deployment().properties.templateLink.uri]"
      },
      "_artifactsLocationSasToken": {
        "type": "securestring",
        "defaultValue": ""
      }
    }
    

    Then reference artifacts only like this:

    "variables": {
      "nestedTemplateUri": "[uri(parameters('_artifactsLocation'), concat('nestedtemplates/template.json', parameters('_artifactsLocationSasToken')))]",
      "scriptFileUri": "[uri(parameters('_artifactsLocation'), concat('scripts/install.sh', parameters('_artifactsLocationSasToken')))]"
    }
    

    Other things you need to notice:

    • Do not manually append the SAS token into _artifactsLocation, and do not pass a signed URI as the _artifactsLocation value. _artifactsLocation must remain the base artifact location only, while _artifactsLocationSasToken must remain the secure token parameter. - https://learn.microsoft.com/en-us/azure/azure-resource-manager/managed-applications/artifacts-location
    • If the deployment history still shows the SAS token appended to _artifactsLocation after confirming the template is correct, then this is a Microsoft platform-side defect/regression in the Azure Managed Applications / Marketplace artifact deployment pipeline. It cannot be permanently fixed from the customer template. So, open an Azure support case via your portal or use Priority Customer Support - PCS: https://learn.microsoft.com/en-us/azure/azure-portal/supportability/priority-community-support and request escalation to Azure Managed Applications / Marketplace engineering, providing the managed application resource ID, managed resource group name, offer/plan/publisher IDs, deployment names, UTC timestamp, and affected correlation IDs. Microsoft documents that deployment history and correlation IDs are used to trace deployment operations for support investigation. - https://docs.azure.cn/en-us/azure-resource-manager/templates/deployment-history
    • Thirdly, immediate mitigation is to treat any exposed SAS URL as compromised for its validity period because a SAS URI is a bearer-access URL; anyone who obtains it can access the referenced artifact while it remains valid. Also, do not place secrets, passwords, private keys, or sensitive publisher IP directly inside ARM templates, nested templates, scripts, or deployment artifacts. Because, that SAS-protected templates should not contain sensitive data such as passwords. - https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/secure-template-with-sas-token
    • For secrets, use managed identities, Key Vault, secure parameters, and runtime retrieval instead of embedding confidential values in Marketplace or Service Catalog artifacts. Also avoid outputting secrets because deployment outputs are stored in deployment history.

    In summary, if your template follows the documented pattern and Azure still records the SAS token inside _artifactsLocation, the issue is not solved by changing the template. But to escalate it as a Microsoft Managed Applications / Marketplace service defect, while immediately removing secrets and sensitive IP from deployment artifacts and using secure runtime secret retrieval instead.

    I hope this is helpful. Please! Do not hesitate to let me know if you have any other questions, steps or clarifications.


    Please do not close the thread by upvoting and accepting the answer if any part of it is helpful.

    Was this answer helpful?


Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.