Does this require authenticated access to the posthog api to kick off? In that case I feel clickhouse and posthog both have their share of the blame here.
Inside PostHog: SSRF, ClickHouse SQL Escape and Default Postgres Creds to RCE
11–20 of 38 posts
Re: Inside PostHog: SSRF, ClickHouse SQL Escape and Default Postgres Creds to RCE
#12Does this require authenticated access to the posthog api to kick off? In that case I feel clickhouse and posthog both have their share of the blame here.
It looks like the entire class of bugs here are "if you have access to Posthog's admin dashboard, you can configure webhook URLs that hit Posthog's internal services". That's not particularly surprising for a self-hosted system like the author's, but I expect it would pretty bad if you were using their cloud-hosted product.
Re: Inside PostHog: SSRF, ClickHouse SQL Escape and Default Postgres Creds to RCE
#13Earlier quoted context omitted.
ssrf was the entry point, and clickhouse is supposed to be an internal only service, but one could reach it only with that ssrf, so hence less of "scrutiny". The 0day by itself wouldnt be useful, unless an attacker can reach clickhouse, which they usually can't.
But if they do, prohibiting SQL injection, a critical last mile vulnerability, seems trivial?
The author already had basically full Clickhouse querying abilities, and Clickhouse lets you run arbitrary SQL on postgres, the fact that the author used a read-only command to execute it wasn't the author bypassing a security boundary (anyone with access to the Clickhouse DB also had access to the Postgres DB), it was just a gadget that made the SSRF more convenient. They could have escalated it into a different internal HTTP API instead.
Re: Inside PostHog: SSRF, ClickHouse SQL Escape and Default Postgres Creds to RCE
#14Earlier quoted context omitted.
looking at their commits, there are about 300+ commits tagged with " Generated with https://claude.com/claude-code " attribution.
Just because AI tools are involved doesn't mean it's "Vibe coding".
It sure is a pretty good indicator, and if you underestimate human laziness you’re gonna have a bad time regardless.
Re: Inside PostHog: SSRF, ClickHouse SQL Escape and Default Postgres Creds to RCE
#15Earlier quoted context omitted.
Just because AI tools are involved doesn't mean it's "Vibe coding".
It sure is a pretty good indicator, and if you underestimate human laziness you’re gonna have a bad time regardless.
Also looking at how much they’ve released and how fast and how they blog like they own the world (or design the website)
I used to look up to Posthog as I thought, wow this is a really good startup. They’re achieving a lot fast actually.
But turns out a lot was sloppy. I don’t trust them no more and would opt for another platform now.
Re: Inside PostHog: SSRF, ClickHouse SQL Escape and Default Postgres Creds to RCE
#16Earlier quoted context omitted.
ssrf was the entry point, and clickhouse is supposed to be an internal only service, but one could reach it only with that ssrf, so hence less of "scrutiny". The 0day by itself wouldnt be useful, unless an attacker can reach clickhouse, which they usually can't.
But if they do, prohibiting SQL injection, a critical last mile vulnerability, seems trivial?
Sure, it’s a bug they can fix. But it’s more the setup itself that’s the issue. For example clickhouse’s HTTP interface would normally require user/pass auth and not have access to all privileges. Clickhouse has a table engine that maps to local processes too (eg select from a python process you pipe stdin into).
No need for postgres if you have a fully authenticated user.
Re: Inside PostHog: SSRF, ClickHouse SQL Escape and Default Postgres Creds to RCE
#17I work on security at PostHog. We resolved these SSRF findings back in October 2024 when this report was responsibly disclosed to us. I'm currently gathering the relevant PRs so that we can share them here. We're also working on some architectural improvements around egress, namely using smokescreen, to better protect against this class of issue.
Re: Inside PostHog: SSRF, ClickHouse SQL Escape and Default Postgres Creds to RCE
#18Re: Inside PostHog: SSRF, ClickHouse SQL Escape and Default Postgres Creds to RCE
#19I work on security at PostHog. We resolved these SSRF findings back in October 2024 when this report was responsibly disclosed to us. I'm currently gathering the relevant PRs so that we can share them here. We're also working on some architectural improvements around egress, namely using smokescreen, to better protect against this class of issue.
Here's the PR[0] that resolved the SSRF issue. This fix was shipped within 24 hours of receiving the initial report.
It's worth noting that at the time of this report, this only affected PostHog's single tenant hobby deployment (i.e. our self hosted version). Our Cloud deployment used our Rust service for sending webhooks, which has had SSRF protection since May 2024[1].
Since this report we've evolved our Cloud architecture significantly, and we have similar IP-based filtering throughout our backend services.
[0] https://github.com/PostHog/posthog/pull/25398
[1] https://github.com/PostHog/posthog/commit/281af615b4874da1b8...
Re: Inside PostHog: SSRF, ClickHouse SQL Escape and Default Postgres Creds to RCE
#20[deleted]