Mittwald: from an MCP token to the projects it can reach
An MCP integration can carry a session’s authority across several projects. The Mittwald case shows why recovery needs to connect credentials, permissions and reopening decisions.
Ler em portuguêsBy Pentesty
The account has dates, scope and limits
In its account published on November 7, Mittwald describes exploitation of a flaw in its MCP server on October 27 and discovery of the incident on November 4. The company reported forensic examination of 56 compromised projects. These are projects, not a customer total. Its hypothesis about AI use comes from the speed seen in logs; the account does not independently establish which tool performed the actions.
The provider’s FAQ says session tokens belonging to users of the interface were read, carrying those users’ rights over their projects, and that these tokens were revoked. The company says passwords were not read. Its dated November 7 update reports mStudio and SSH restored; MCP remained offline and some sites remained blocked. Older answers on the same FAQ saying SSH was blocked must be read in light of that update.
Map session reach before planning recovery
In an authorized enterprise assessment, start with a map of the user, integration, session and project. Add the role held in each project and the services it can administer. The team owning an integration may differ from the team responsible for customer data. The response plan needs to capture that relationship.
Record when the credential was issued, its owner and which permissions changed during the investigated interval. Current reach may differ from earlier reach. Our ARTEX analysis of application secrets and authority helps organize this dependency while preserving the differences between applications and user sessions.
Separate revocation, authentication and project credentials
Define separate evidence for ending the session, protecting the next login and replacing other access that may have been reachable. A screen requesting authentication again does not, by itself, demonstrate the outcome across every consuming service. Establish where the decision was enforced and which test sessions remain valid.
Mittwald’s guidance to affected users includes reviewing unknown SSH, API and project entries and renewing third-party service credentials stored in projects. To apply that logic in your environment, assign owners to each dependency and a replacement order that preserves legitimate operations. Keep action identifiers in the evidence, with secrets excluded from those records.
Test the boundary with your own identities and projects
Prepare an isolated environment with two synthetic identities and projects containing no customer data. Give each identity its approved permissions and document permitted access before the change. Then withdraw an authorization or end the session through the supported mechanism. Verify the expected denial and confirm that the other identity’s authorized work remains available.
Perform only harmless operations covered by the agreed scope. Retain the time, test identity, project, action and service decision to correlate each attempt with logs. This exercise assesses the organization’s own design; it neither reproduces a flaw against the provider nor proves the technical mechanism behind the reported incident.
Recovery is also a decision for each project
Each project needs an owner to review changes, added access, dependencies and restoration evidence. A scan without alerts is useful information, but it needs to be considered alongside the investigated interval and available records. If restoration is required, document which legitimate changes will be preserved and how the team will validate the result.
Reopen services in approved stages and monitor reading and administration with the new credentials. Decide who stops recovery if an ended identity is accepted again or a change appears without a known origin. Outstanding issues need owners, deadlines and an explicit effect on whether the project can operate.
Accept the integration with repeatable evidence
The deliverable can combine the authority map, permitted and denied results, credential replacements and approval by project owners. Record what remained unobserved too. At the next integration change, repeat the same cases with synthetic data. That continuity supports risk discussions with evidence from the environment, without turning the presence of MCP or a hypothesis about AI into an automatic explanation for every incident.
Frequently asked questions
Does the account confirm that an AI performed the attack?
Mittwald infers AI tooling from the recorded speed. That does not independently establish which agent or model was used.
Do 56 projects mean 56 customers?
No. The account counts compromised projects. It does not equate that number with unique customers.
Does a password change prove a stolen session has ended?
The termination mechanism and expected denial need verification. Protecting new logins and revoking sessions require different evidence.
Does the assessment require testing against Mittwald?
The proposed exercise uses your own identities and projects in an authorized environment. Provider information informs the assessment without authorizing tests against third parties.
Sources and references
- Mittwald: incident account dated November 7, 2026
- Mittwald: FAQ and updates, including the November 7 update
Original Pentesty analysis, published November 9, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.