The vulnerability lies in the handleBlueBubblesWebhookRequest function, which is responsible for processing incoming webhooks for the BlueBubbles iMessage integration. The analysis of the provided patches, specifically commit f836c385ffc746cb954e8ee409f99d079bfdcd2f, reveals the exact code that caused the vulnerability. The removed lines show a check that explicitly allowed requests from loopback addresses to be processed without proper authentication. This created a significant security hole, as any process on the same machine (including a reverse proxy forwarding external requests) could impersonate an authenticated service.
The subsequent defense-in-depth commit, 743f4b28495cdeb0d5bf76f6ebf4af01f6a02e5a, further confirms that this area of the code was the source of the problem. It introduces a more sophisticated check, isDirectLocalLoopbackRequest, to distinguish between genuine direct loopback requests and those that are proxied, hardening the authentication logic. Therefore, during an exploit scenario on a vulnerable version, the handleBlueBubblesWebhookRequest function would be the primary function appearing in a runtime profile as it processes the malicious, unauthenticated webhook.