CVE-2026-0234 is an improper cryptographic signature verification flaw (CVSS 9.1 in the record) in the Microsoft Teams integration for Cortex XSOAR and Cortex XSIAM. It lets an unauthenticated user reach and change protected resources. Palo Alto Networks says to upgrade the Microsoft Teams marketplace pack to 1.5.52 or later.
What's affected
From the Palo Alto Networks advisory: the Microsoft Teams Marketplace pack for Cortex XSOAR and Cortex XSIAM, versions 1.5.0 up to but not including 1.5.52. Version 1.5.52 and later is unaffected.
The vendor scores it 7.2 with its own threat adjusted method (9.2 base on CVSS 4.0), and the NVD record shows 9.1 on CVSS 3.1. Both are given here so you can see the spread.
How to check if you're exposed
In the XSOAR or XSIAM marketplace, open the installed content packs and read the version of the Microsoft Teams pack. Any version from 1.5.0 to 1.5.51 is affected. Also check whether the Teams integration is enabled and reachable from the internet, since the vector is network based.
What to do now
- Upgrade the Microsoft Teams marketplace pack to 1.5.52 or later.
- Confirm the new version is active on all engines and tenants.
- The vendor lists no workaround, so patching is the only mitigation.
- Review integration logs for unexpected inbound requests to the Teams endpoint.
- Review what the Teams integration can modify, and reduce its permissions if they are broad.
Orchestration platforms connect to many other tools, which is why a weak entry point there deserves attention. A message that passes a signature check is treated as trusted input, and in an automation platform trusted input can start playbooks and change data.
After you upgrade the pack, check which playbooks and integrations the Teams connector can trigger. Remove access that is not needed. If the Teams integration is no longer used, remove the pack altogether, since an unused integration adds exposure with no benefit.
Also compare the two scores you will see. The vendor gives 7.2 with its threat adjusted method, and NVD shows 9.1. The difference comes from the scoring model and the weight given to attack complexity. Use the higher number to set a deadline, not to stop reading.
Why it matters
The weakness is CWE-347 (improper verification of cryptographic signature). A signature on an inbound message is the proof that it came from the expected sender. If the check is flawed, an outsider can send messages the platform treats as trusted. For a security orchestration product, trusted inbound messages can drive actions, which is why the integrity score is high.
Palo Alto Networks says it is not aware of malicious exploitation, and the record does not mark it as KEV.
Signature checks are easy to get subtly wrong. The code has to confirm that the signature is valid, that it matches the expected key, and that it covers the content that is acted on. A gap in any of those steps can let a forged message through.
For you, the point is to keep integrations current and small in number.
Quick check
Is there a workaround?
The vendor says no known workarounds exist. Upgrade the pack to 1.5.52 or later.
If you want a quick look at your own dependencies, the free in-browser scan at gold.safeguard.sh/scan needs no repository access.
Sources
Fetched for this guide:
Last reviewed: 19 October 2026.
