Multiple Vulnerabilities in Deloitte AI Assist Ascend Platform - five CVE classes, six tenants, published at Day 63 disposition checkpoint

The canonical artifact for this advisory is the PGP-signed PDF below. The HTML content on this page is a reading surface for vendors, SBIR/contract evaluators, search engines, and accessibility tooling; the PDF is the load-bearing, cryptographically-signed reference. Hash and signature pin the PDF bytes; CERT/CC VINCE case archives provide an independent trust anchor.

gpg --verify deloitte-aiassist-ascend-2026-vu487875.pdf.asc deloitte-aiassist-ascend-2026-vu487875.pdf

ZERO|TOLERANCE Security Research identified five classes of high-severity vulnerabilities in Deloitte's AI Assist platform (internally branded Ascend), an enterprise AI/ML workflow product delivered as multi-tenant SaaS to Fortune 500 clients. The vulnerabilities were observed in every assessed tenant deployment (6 of 6), including Deloitte's own production and development environments.

Findings include unauthenticated access to Keycloak administrative consoles across six production tenants, twelve backend API endpoints exposed without authentication on the primary assessment subject, server-side request forgery via configuration injection, password-grant authentication exposed on public OAuth clients with no rate limiting, and unauthenticated access to retrieval-augmented generation (RAG) document corpora with confirmed write-path for content poisoning.

All findings are exploitable from the public internet using only standard HTTP requests. No credentials, no authentication bypass, no exploitation primitives are required. The vulnerabilities were verified via passive reconnaissance and read-only API interaction. Reassessment activity across Day 3/4 (2026-03-19), Day 8 (2026-03-24), and Day 63 (2026-05-16) records a divergent remediation posture by environment: substantial decommission and rebuild work at five of six client environments, an active regression at the production Keycloak layer, and one architectural defect (password grant on public OAuth clients) that remains unfixed at Day 63.

Highest CVSS: 9.1 CRITICAL (AV:N/AC:L/PR:N/UI:N/S:C). Exploitation status: no known in-the-wild exploitation observed by ZERO|TOLERANCE Security Research.

Deloitte AI Assist platform (Ascend), deployed across the following observed tenants. Each tenant operates as an independent multi-tenant slice of the shared platform infrastructure. Each tenant operates a dedicated Keycloak identity instance, Azure API Management gateway, and backend service mesh, all internet-exposed at the time of initial disclosure.

Affected versions. This is a vendor-operated SaaS platform; no customer-installable versions apply. Scope is bounded by the Day 0 (2026-03-13) through Day 63 (2026-05-16) observation window.

Tenant identification. Tenant identities for A, B, and C are documented in CERT/CC VINCE case materials and available to the coordinator for vendor notification. This advisory presents corroborating tenant evidence in sector form to demonstrate the tenant-model defect without expanding incident disclosure beyond the primary assessment scope. Notification of affected tenants is a vendor responsibility under coordinated vulnerability disclosure norms.

Full per-CVE detail including endpoint inventories, HTTP capture evidence, and resource-hash verification across the reassessment cycle is documented in the canonical PDF advisory.

Publication on Day 63 follows the early coordinated close provision in ZT Disclosure Policy v1.6 §4.

Coordination stance. This advisory was published on the date proposed via the CERT/CC coordination thread (2026-05-12) and accepted on-thread.

Reassessments were conducted at Day 3/4 (2026-03-19), Day 8 (2026-03-24), and Day 63 (2026-05-16) post-disclosure, each applying the same passive-reconnaissance methodology used in the original assessment. Between Day 8 and Day 63 the remediation picture diverged sharply by environment. Findings break into four buckets:

Disposition Scorecard by Category

Full 59-item findings annex with per-item evidentiary status and reassessment captures available in Appendix A of the canonical PDF.

The following mitigations apply to the vendor and to any organization operating a multi-tenant identity-fronted SaaS platform with comparable architecture.

Immediate (within 24 hours)

• Restrict Keycloak administrative console access to authenticated administrative networks only. Block public-internet access at the load balancer or Azure Application Gateway layer.
• Disable the password grant type across all public-facing OAuth clients. Disable implicit grant.
• Disable admin-cli access on master realms. If admin-cli is required operationally, restrict to internal-only network reachability.
• Enforce authentication on all /auth-service/v1/manage/*, /app-config/v1/config/*, and /rag-service/v1/rag/* endpoints at the API Management gateway layer.
• Audit Keycloak realm exports for unauthorized OIDC clients added during the exposure window.

Within 7 days

• Audit the production configuration store for unauthorized records, including the test records in the id:9 through id:12 range.
• Implement rate-limiting and account-lockout policies on the identity plane.
• Audit the RAG corpus for unauthorized ingested content.

Within 30 days

• Reassess the multi-tenant deployment template that propagates these defects across new tenant onboarding.
• Implement authentication-by-default policy for all internal service-to-service communication.
• Conduct third-party verification of remediation against the 59-item tracked inventory, with particular attention to Bucket 5.3 (regressed production Keycloak) and Bucket 5.4 (architectural password-grant defect).

Detection Guidance

• API Management gateway logs: review for unauthenticated 2xx responses on the endpoint patterns listed in CVE-2026-TBD-002.
• Keycloak administrative console access logs: review for sessions originating from non-administrative networks during the exposure window.
• Configuration store audit: query for base_url values not matching the operator's allowlist of permitted integration partners.
• RAG corpus audit: review ingested documents for content lacking expected client-origin metadata during the exposure window.

References

• CERT/CC VU#487875
• CWE-306 Missing Authentication for Critical Function
• CWE-918 Server-Side Request Forgery
• CWE-521 Weak Password Requirements
• CWE-639 Authorization Bypass Through User-Controlled Key
• CVE assignments coordinated through CERT/CC at publication; identifiers will be appended upon issuance.

Acknowledgments

Coordinated through CERT/CC VINCE (VU#487875). CISA Vulnerability Response Coordination engaged as of 2026-04-21 (ANALYGENCE / CISA VRC).

This advisory was prepared by Karim El Labban, ZERO|TOLERANCE Security Research. The findings were validated via passive reconnaissance and read-only API interaction. No credentials were used, created, or brute-forced. No data was exfiltrated beyond what was returned in standard HTTP responses to unauthenticated requests. All testing was conducted from a single attribution-clean IP. Test artifacts are documented in CERT/CC case materials.

For coordinated disclosure inquiries or to verify advisory integrity, contact security@zerotolerance.me. Public key 0x7BD71863418DC1BE is published on keys.openpgp.org and at /.well-known/pgp-key.txt.

← Back to Advisories Index