DBHunter
Infinity Member
Golden Member
- Joined
- August 23, 2025
- Messages
- 2,152
- Reaction score
- 4,303
- Points
- 113
- Thread Author
- #1
THE HATICA LEAKS
75 private repositories • 5.7 GB DixiApp production database • 4,700 customer Slack bot tokens • 134,270 Jira issues • 119 Posium user accounts • 36 unique production credentials • customer application passwords in plaintext
Download complete archive here (~7.6 GB):
ONE GITHUB TOKEN -> 4,700 COMPANIES.
Hatica is a Sequoia-backed engineering management platform that promises to measure developer productivity without being invasive. It integrates with your GitHub, your Jira, your Slack, your calendar -- and computes metrics about how your engineers spend every hour of their working day. Over 600 companies have trusted Hatica with this data, including Disney, MIT, Hotstar, Truecaller, PayPay Corporation, Viacom18, ShareChat, and EPAM Systems. Surge -- Sequoia India's accelerator -- led their seed round. They have raised $6.59 million and report $1.8 million in annual recurring revenue.
What most of these companies do not know is that Hatica also operates two other products under the same infrastructure: DixiApp (later rebranded PyjamaHR), a Slack standup bot that has been installed in 4,700 workspaces since 2019, and Posium (also branded QAKit), an AI-powered test automation platform whose customers include JP Morgan, BrowserStack, GE Healthcare, and Allica Bank.
All it took was one GitHub token with access to private repos overflowing with hardcoded credentials. We obtained that token. And then we obtained everything else.
THE REPOS
We are releasing the complete contents of the 'haticahq' GitHub organisation -- all 75 private repos. The core platform is split across two monorepos:
'astro' -- The current Hatica backend. Seventeen microservices: appcore, cewriter, chrono, conduit, fletcher, gateway, goal, hook, integro, slacker, stat, surveyor, webapp, and edison. This is the DORA metrics engine, the 'Maker Time' analysis algorithms, the GitHub/GitLab/Bitbucket connectors, the Jira/Linear/ClickUp integrators, and the Slack bot -- the complete intellectual property that Sequoia's money paid for.
'posium-core' -- The next-generation QA testing platform. Thirteen applications including platform-api, qakit-api, qakit-sdk, qakit-smtp, browser-manager (Playwright-based), runner, subber, admin, jobber, reporter-api, and webapp. Eighteen internal packages covering AI, billing, core database, and pub/sub.
'dixiapp-backend' -- The legacy Django backend for DixiApp/PyjamaHR, complete with production environment files containing every credential the application has ever used.
'helm-charts' -- 35 Kubernetes Helm charts for every service in the stack. 'ranch' -- Kustomize deployment configurations for 17 services. 'onprem' -- The on-premises deployment package, which ships with all production secrets stored as plaintext values in values.yaml.
And 69 more. All of their proprietary algorithms, their integration connectors, their billing system, their infrastructure topology, their deployment secrets. LinearB and Jellyfish -- Hatica's primary competitors -- will find this educational.
HARDCODE THOSE CREDS AND GIT COMMIT -- WHAT COULD GO WRONG?
Those repositories contained production environment files, Helm charts, and deployment configs with credentials for every service Hatica has ever used. Hundreds of unique credentials across 15 services, 37 of them verified live by Trufflehog, all in plaintext. We followed them like a trail of breadcrumbs.
The Statsig server secret ('secret-7kmq07hS7IhqGhaevxtZ1ZC8HOyQ2hTvwDqdaAhqIbM') led to the Wasabi S3 bucket credentials via 'download_config_specs', which gave us the customer test case database -- containing real login credentials for Fortune 500 customer applications (more on that below). The AlloyDB connection string ('temporal:s0skvAamKNhx8wV' at 'obi-alloydb.haticainternal.com') gave us the production databases for all three products. The AWS SES SMTP credentials ('AKIA5XG5MJKTRAUPMX6R:BCZ7mJZFjj5bYZlvVvhET8I4NP04jfNa5SxyegfrPt6R') let us send email as 'notifications@hatica.io' -- Hatica's own notification address. We used it to notify them of the breach
The credential encryption secret: 'cqVuqEOrVtNf8JJrzWfAneOrZdx7SVcJnd8/EQ4Lc9s='. This is the key Hatica uses to encrypt stored OAuth tokens for customer integrations. Every company that connected their GitHub, Jira, or Slack to Hatica handed over OAuth credentials that were encrypted with this key.
Two Mailgun tokens ('0a9c2466067e91da8aa260ba621ee436-9dda225e-d8f2792d' and 'key-90627c957fb8e95e7d4602b06a9db4e0') control 101+ custom email subdomains on 'pyjamahr.com', each belonging to a different DixiApp customer organisation. Incredibly, these were still active nearly two weeks after we used them to notify Hatica of the breach.
For anyone running Hatica's on-premises deployment: the values.yaml ships with Redis password 'qwertyuiop', Hasura admin secret 'qawsedrft2', SAMLJackson API keys 'keys', and NextAuth secret 'secret'.
The remaining credentials include their enterprise AI API Keys OpenAI ('sk-proj-G5W3yfV4A9Adu4JF1M7TT3BlbkFJie7GCgV9TQRSdjVfy5dq'), Anthropic ('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'). We appreciate those and have gotten a lot out of them, thank you!
See the full secrets dump in the download for the rest: PostHog, Resend, five Slack webhooks, two Slack bot tokens, two Slack client secrets, production RDS, internal PostgreSQL, staging PostgreSQL, Kubernetes PostgreSQL, ClickHouse, Elasticsearch, Hasura action secret, Celery Flower, Sentry DSNs, email SMTP, Django secret key, and token secret key, 'hustleandwin'.
Keep hustling and winning, Hatica.
4,700 SLACK WORKSPACES: THE DIXIAPP LEGACY
This is the part that makes this breach unusual. DixiApp was Hatica's first product -- a Slack standup bot launched in 2019. Companies installed it, granted it OAuth access to their workspaces, and used it to collect daily standup reports from their engineering teams. Over five years, 4,700 companies did this.
When Hatica pivoted to its current engineering analytics platform, DixiApp did not disappear. The production database kept running. The Slack bot tokens kept working. And the 5.7 GB PostgreSQL database -- containing every standup answer, every team roster, every Slack channel configuration from 2019 to 2026 -- remained accessible via the credentials we extracted from the source code.
We dumped the lot. 85 tables. 140,472 rows at the internal level. The 'bot_team' table alone contains 4,700 Slack bot access tokens (xoxb-*). We verified the most recent token:
Code:
NS TOPAAS is a division of Dutch National Railways (NS). The token is live. We enumerated 168 channels and 198 employee email addresses -- all @ns.nl -- including CPOs, architects, security leads, and data scientists. The complete corporate directory of a European national rail infrastructure team, accessible through a standup bot that Hatica forgot about.
Other notable workspaces with tokens in the database:
Code:
Through these tokens we enumerated the complete employee directories of every active workspace -- names, corporate email addresses, job titles, team structures. The 'bot_answer' table in the database itself contains over 10,000 standup entries: years of daily work updates from employees at Seller Tools, Hatch, Clinis, MoEngage, Clanbeat, and Doctissimo, among others. Security credential changes. Production database work. Competitor intelligence gathering. Feature development details. Business strategy discussions. All captured by a standup bot, all exfiltrated.
THE POSIUM CUSTOMER DATABASE: JP MORGAN, BROWSERSTACK, GE HEALTHCARE
Hatica's newest product, Posium (posium.ai), is an AI-powered test automation platform. Its production AlloyDB database -- extracted at 35.227.224.151 -- contained 119 registered users from companies you would not expect to find in the breach of a <$3M ARR startup:
- james.massa@jpmorgan.com -- JP Morgan
- shashank.j@browserstack.com, amit.ba@browserstack.com -- BrowserStack
- enzo.bolis@gehealthcare.com -- GE Healthcare
- naveen.kanak@allica.bank -- Allica Bank
- kalyana.srinivas@katalon.com -- Katalon
- thomas@localglobe.vc -- LocalGlobe VC
- Five employees from SAFE Security (gaurav.g@, saksham.s@, lokendra.h@, kasak.g@, raghavendra.b@safe.security)
Then there's the 'project_variable' table, a credentials vault -- 78 rows of plaintext usernames and passwords that Posium's customers stored for their automated test suites. These are login credentials for real customer applications:
adam.moore@constellationfs.com | V!$ion648206 | training.prolender.net (lending platform)
patryk1@getbueno.com | Test1234 | app-dev.getbueno.com
andy@forkts.com | test1234 | app.sparkinventory.com
harish@posiumhq.com | Pass@word!1 | demo.safeone.io (SAFE Security)
asagar@posiumhq.com | jf4SxgSTVJ%jRh | app.athenaintel.com (Athena Intel)
Constellation Financial Software. SAFE Security. Athena Intel. Spark Inventory. Bueno. These are not Hatica's customers -- they are Hatica's customers' customers, and their login credentials were sitting in a plaintext database because Posium's architecture required storing them unencrypted for automated browser testing. Anyone with access to this database can log into these applications as these users. Which is exactly what we did.
The database also contained 696 AI chat conversations -- complete records of Posium's AI test planning sessions with customer application URLs, test scenarios, and internal state for apps at demo.safeone.io, homegate.ch, and various customer staging environments. And 6 active session tokens at time of extraction, including one for sjoshi@hatica.io (Sachin Joshi, Hatica co-founder) valid as an admin session on qakit.posium.ai.
134,270 JIRA ISSUES: THE CUSTOMER INTELLIGENCE TROVE
The CTO's Jira API token -- belonging to hsingh@hatica.io (Haritabh Singh) -- gave us access to hatica.atlassian.net: 19 projects, 134,270 issues, 122 Jira users.
The Customer Success project alone identifies 40+ enterprise customers by name, with support ticket histories, integration configurations, and employee contact information:
Hotstar (Disney+) -- 33 issues. Employee emails: soham.majumdar@, abhishek.awale@, sundarapandyan.sa@, nitya.tiwari@, amarnath@.
Viacom18 (Paramount/Reliance) -- 15 issues. Ticket CS-185 contains a telling admission: 'We are contractually obligated to NOT show any individual level data.' The contractual data handling restriction that Hatica documented in plaintext Jira tickets -- the same Jira instance we accessed trivially.
PayPay Corporation (Japan) -- 9 issues. Truecaller -- 7 issues. ShareChat -- 13 issues. Moglix -- 25 issues. EPAM Systems -- 1 issue. SwissMarketplace Group -- 16 employee emails extracted.
175 unique email addresses across 73 company domains. A spear-phishing campaign's worth of verified corporate contacts, all sourced from the engineering management platform those companies trusted with their data.
The Compliance project -- 22 issues -- documents Hatica's own Vanta security audit failures:
- 10 EC2 instances with public SSH access (including 'security-monitor-01' -- the irony writes itself)
- 20+ S3 buckets without Block Public Access enabled
- Critical Dependabot vulnerabilities left unpatched: arbitrary code execution in Babel, SSRF in parse-url, authorisation bypass in parse-path
This is a company that markets itself as SOC 2 Type II compliant.
THE GCP INFRASTRUCTURE
The github-ci@posium.iam.gserviceaccount.com service account gave us:
- 8 Cloud Run services in us-central1, all deployed by the compromised CI account
- Full container registry access: 6 Docker images pulled (platform-api, qakit-api, qakit-smtp, reporter-api, runner, webapp)
- 5 Wasabi S3 buckets: 6,243 files totalling 5.1 GB of test screenshots, Playwright trace files, and test case source code containing customer credentials
A LOT OF LETTERS TO SEND
The notification obligations here are extraordinary.
DixiApp/PyjamaHR Slack customers: 4,700
Mailgun customer email domains: 101
Hatica engineering metrics customers (Jira): 40+
Posium/QAKit customers (credentials): 11+
Total: 4,850+
GDPR applies to Hatica's EU customers -- NS TOPAAS (Dutch National Railways), Doctissimo (France), SwissMarketplace Group, multiple others. Japan's APPI covers PayPay Corporation. India's DPDP Act covers Hotstar, ShareChat, Moglix, and dozens more. The estimated fine exposure under GDPR alone could be as high as 20 million EUR or 4% of annual turnover -- though for a company generating less than $3 million annually, the reputational damage will kill them long before the fines arrive. To say nothing of the lawsuits coming their way.
TO HATICA, AND TO NAOMI CHOPRA AND HARITABH SINGH
You built a platform that asks engineering teams to hand over their most sensitive operations data -- commit histories, code review patterns, meeting schedules, productivity metrics -- and you stored the keys to all of it in plaintext environment files committed to GitHub repositories. Your token signing key is 'hustleandwin'. Your credential encryption key -- the one that protects the OAuth tokens your customers entrusted to you -- was sitting in a values.yaml file alongside a NextAuth secret that is literally the word 'secret'.
You claim to be SOC 2 Type II compliant. Your own Jira compliance project documents 10 EC2 instances with public SSH, 20 S3 buckets without public access blocks, and critical code execution vulnerabilities left unpatched. Your security monitor server -- 'security-monitor-01' -- had its SSH port open to the internet.
You asked 600 companies to trust you with the inner workings of their engineering teams. You asked 4,700 companies to install a Slack bot that could enumerate their employees. You asked JP Morgan, BrowserStack, and GE Healthcare to store test credentials in your platform. And you protected all of it with a GitHub token that had 'delete_repo' scope. Yes, we could have deleted the entirety of your Github org, but we are not vandals; we prefer to let your own actions (and lack thereof) do the damage. Although that would have certainly been one way to sanitise a codebase leaking so many credentials.
You could have prevented this every step of the way. You could have patched your vulnerable servers; you could have sanitised your repos of hardcoded credentials; you could have taken us up on our very reasonable offer. But you did none of these things.
We hope you like writing breach notifications as much as we do.
---
THE DATA
The structure is as follows:
Source Code (75 repos, full git history -- in 'haticahq' archive within main archive):
- haticahq/astro/ -- Main backend monorepo (17 services)
- haticahq/posium-core/ -- QA testing platform monorepo (13 apps, 18 packages)
- haticahq/dixiapp-backend/ -- Legacy Django backend with production env files
- haticahq/dixiapp-frontend/ -- Legacy React frontend
- haticahq/helm-charts/ -- 35 Kubernetes Helm charts
- haticahq/ranch/ -- Kubernetes kustomize configs
- haticahq/onprem/ -- On-premises deployment with plaintext secrets
- 68 additional repositories (conduit, mason, milo, fusion, cube, events-api, amplify-notify, growth-monitor, qakit, posium-*, BI dashboards, monitoring tools, and more)
Production Databases:
- dixi_app/dixi_app_FULL.json -- 5.7 GB complete DixiApp production database (85 tables, 140,472+ rows, 4,700 Slack bot tokens)
- alloydb_dumps/posium_all_tables.json -- 16 MB Posium AlloyDB dump (119 users, 497 sessions, 78 project variables, 696 AI chats)
- alloydb_dumps/qakit_db_complete.json -- 675 KB QAKit database (92 orgs, 246 projects, 65 inboxes, 306 captured emails)
Jira:
- hatica_jira_full_dump/ -- 134,270 issues across 19 projects, 175 customer emails, Vanta audit failures
Cloud Storage:
- wasabi_reporter/ -- 311 files, 373 MB (test results)
- wasabi_reporter-dev/ -- 4,143 files, 4.5 GB (dev test results)
- wasabi_test-cases/ -- 170 files with customer credentials
- wasabi_f0-reporter-dev/ -- 1,598 files, 310 MB
- wasabi_cosium-reporter-dev/ -- 21 files
Docker Images:
- platform-api, qakit-api, qakit-smtp, reporter-api, runner, webapp -- 2.5 GB total
Infrastructure:
- GCP enumeration data (service accounts, Cloud Run services) and API key enumeration data
- Redis dumps (production and cloud)
- Mailgun domain data (101+ customer subdomains)
- Statsig configuration
- PostHog feature flags
If you are a customer of Hatica, DixiApp, PyjamaHR, or Posium/QAKit, you should assume your integration credentials have been compromised. Rotate your GitHub tokens, Jira API keys, and Slack OAuth grants immediately.
We suggest giving them a call letting them know how much you appreciate their security posture putting your entire organisation at risk.
75 private repositories • 5.7 GB DixiApp production database • 4,700 customer Slack bot tokens • 134,270 Jira issues • 119 Posium user accounts • 36 unique production credentials • customer application passwords in plaintext
Download complete archive here (~7.6 GB):
ONE GITHUB TOKEN -> 4,700 COMPANIES.
Hatica is a Sequoia-backed engineering management platform that promises to measure developer productivity without being invasive. It integrates with your GitHub, your Jira, your Slack, your calendar -- and computes metrics about how your engineers spend every hour of their working day. Over 600 companies have trusted Hatica with this data, including Disney, MIT, Hotstar, Truecaller, PayPay Corporation, Viacom18, ShareChat, and EPAM Systems. Surge -- Sequoia India's accelerator -- led their seed round. They have raised $6.59 million and report $1.8 million in annual recurring revenue.
What most of these companies do not know is that Hatica also operates two other products under the same infrastructure: DixiApp (later rebranded PyjamaHR), a Slack standup bot that has been installed in 4,700 workspaces since 2019, and Posium (also branded QAKit), an AI-powered test automation platform whose customers include JP Morgan, BrowserStack, GE Healthcare, and Allica Bank.
All it took was one GitHub token with access to private repos overflowing with hardcoded credentials. We obtained that token. And then we obtained everything else.
THE REPOS
We are releasing the complete contents of the 'haticahq' GitHub organisation -- all 75 private repos. The core platform is split across two monorepos:
'astro' -- The current Hatica backend. Seventeen microservices: appcore, cewriter, chrono, conduit, fletcher, gateway, goal, hook, integro, slacker, stat, surveyor, webapp, and edison. This is the DORA metrics engine, the 'Maker Time' analysis algorithms, the GitHub/GitLab/Bitbucket connectors, the Jira/Linear/ClickUp integrators, and the Slack bot -- the complete intellectual property that Sequoia's money paid for.
'posium-core' -- The next-generation QA testing platform. Thirteen applications including platform-api, qakit-api, qakit-sdk, qakit-smtp, browser-manager (Playwright-based), runner, subber, admin, jobber, reporter-api, and webapp. Eighteen internal packages covering AI, billing, core database, and pub/sub.
'dixiapp-backend' -- The legacy Django backend for DixiApp/PyjamaHR, complete with production environment files containing every credential the application has ever used.
'helm-charts' -- 35 Kubernetes Helm charts for every service in the stack. 'ranch' -- Kustomize deployment configurations for 17 services. 'onprem' -- The on-premises deployment package, which ships with all production secrets stored as plaintext values in values.yaml.
And 69 more. All of their proprietary algorithms, their integration connectors, their billing system, their infrastructure topology, their deployment secrets. LinearB and Jellyfish -- Hatica's primary competitors -- will find this educational.
HARDCODE THOSE CREDS AND GIT COMMIT -- WHAT COULD GO WRONG?
Those repositories contained production environment files, Helm charts, and deployment configs with credentials for every service Hatica has ever used. Hundreds of unique credentials across 15 services, 37 of them verified live by Trufflehog, all in plaintext. We followed them like a trail of breadcrumbs.
The Statsig server secret ('secret-7kmq07hS7IhqGhaevxtZ1ZC8HOyQ2hTvwDqdaAhqIbM') led to the Wasabi S3 bucket credentials via 'download_config_specs', which gave us the customer test case database -- containing real login credentials for Fortune 500 customer applications (more on that below). The AlloyDB connection string ('temporal:s0skvAamKNhx8wV' at 'obi-alloydb.haticainternal.com') gave us the production databases for all three products. The AWS SES SMTP credentials ('AKIA5XG5MJKTRAUPMX6R:BCZ7mJZFjj5bYZlvVvhET8I4NP04jfNa5SxyegfrPt6R') let us send email as 'notifications@hatica.io' -- Hatica's own notification address. We used it to notify them of the breach
The credential encryption secret: 'cqVuqEOrVtNf8JJrzWfAneOrZdx7SVcJnd8/EQ4Lc9s='. This is the key Hatica uses to encrypt stored OAuth tokens for customer integrations. Every company that connected their GitHub, Jira, or Slack to Hatica handed over OAuth credentials that were encrypted with this key.
Two Mailgun tokens ('0a9c2466067e91da8aa260ba621ee436-9dda225e-d8f2792d' and 'key-90627c957fb8e95e7d4602b06a9db4e0') control 101+ custom email subdomains on 'pyjamahr.com', each belonging to a different DixiApp customer organisation. Incredibly, these were still active nearly two weeks after we used them to notify Hatica of the breach.
For anyone running Hatica's on-premises deployment: the values.yaml ships with Redis password 'qwertyuiop', Hasura admin secret 'qawsedrft2', SAMLJackson API keys 'keys', and NextAuth secret 'secret'.
The remaining credentials include their enterprise AI API Keys OpenAI ('sk-proj-G5W3yfV4A9Adu4JF1M7TT3BlbkFJie7GCgV9TQRSdjVfy5dq'), Anthropic ('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'). We appreciate those and have gotten a lot out of them, thank you!
See the full secrets dump in the download for the rest: PostHog, Resend, five Slack webhooks, two Slack bot tokens, two Slack client secrets, production RDS, internal PostgreSQL, staging PostgreSQL, Kubernetes PostgreSQL, ClickHouse, Elasticsearch, Hasura action secret, Celery Flower, Sentry DSNs, email SMTP, Django secret key, and token secret key, 'hustleandwin'.
Keep hustling and winning, Hatica.
4,700 SLACK WORKSPACES: THE DIXIAPP LEGACY
This is the part that makes this breach unusual. DixiApp was Hatica's first product -- a Slack standup bot launched in 2019. Companies installed it, granted it OAuth access to their workspaces, and used it to collect daily standup reports from their engineering teams. Over five years, 4,700 companies did this.
When Hatica pivoted to its current engineering analytics platform, DixiApp did not disappear. The production database kept running. The Slack bot tokens kept working. And the 5.7 GB PostgreSQL database -- containing every standup answer, every team roster, every Slack channel configuration from 2019 to 2026 -- remained accessible via the credentials we extracted from the source code.
We dumped the lot. 85 tables. 140,472 rows at the internal level. The 'bot_team' table alone contains 4,700 Slack bot access tokens (xoxb-*). We verified the most recent token:
Code:
ok=true | team=NS TOPAAS | user=dixiapp | url=https://ns-topaas.slack.com/NS TOPAAS is a division of Dutch National Railways (NS). The token is live. We enumerated 168 channels and 198 employee email addresses -- all @ns.nl -- including CPOs, architects, security leads, and data scientists. The complete corporate directory of a European national rail infrastructure team, accessible through a standup bot that Hatica forgot about.
Other notable workspaces with tokens in the database:
Code:
Code:
PayPal | T0G9AL7B8 | 44 users
Citrix | T02FHCP3E | 20 users
Rakuten Digital | T1Y50SUCA | 6 users
Rakuten Data Platform | TGJ8HQA69 | 19 users
Ruangguru (Indonesian EdTech unicorn) | T02LAQVRG | 59 users
MoEngage | T02FYRSTM | 12 users
FranklinCovey | T025EUVSP | ActiveThrough these tokens we enumerated the complete employee directories of every active workspace -- names, corporate email addresses, job titles, team structures. The 'bot_answer' table in the database itself contains over 10,000 standup entries: years of daily work updates from employees at Seller Tools, Hatch, Clinis, MoEngage, Clanbeat, and Doctissimo, among others. Security credential changes. Production database work. Competitor intelligence gathering. Feature development details. Business strategy discussions. All captured by a standup bot, all exfiltrated.
THE POSIUM CUSTOMER DATABASE: JP MORGAN, BROWSERSTACK, GE HEALTHCARE
Hatica's newest product, Posium (posium.ai), is an AI-powered test automation platform. Its production AlloyDB database -- extracted at 35.227.224.151 -- contained 119 registered users from companies you would not expect to find in the breach of a <$3M ARR startup:
- james.massa@jpmorgan.com -- JP Morgan
- shashank.j@browserstack.com, amit.ba@browserstack.com -- BrowserStack
- enzo.bolis@gehealthcare.com -- GE Healthcare
- naveen.kanak@allica.bank -- Allica Bank
- kalyana.srinivas@katalon.com -- Katalon
- thomas@localglobe.vc -- LocalGlobe VC
- Five employees from SAFE Security (gaurav.g@, saksham.s@, lokendra.h@, kasak.g@, raghavendra.b@safe.security)
Then there's the 'project_variable' table, a credentials vault -- 78 rows of plaintext usernames and passwords that Posium's customers stored for their automated test suites. These are login credentials for real customer applications:
adam.moore@constellationfs.com | V!$ion648206 | training.prolender.net (lending platform)
patryk1@getbueno.com | Test1234 | app-dev.getbueno.com
andy@forkts.com | test1234 | app.sparkinventory.com
harish@posiumhq.com | Pass@word!1 | demo.safeone.io (SAFE Security)
asagar@posiumhq.com | jf4SxgSTVJ%jRh | app.athenaintel.com (Athena Intel)
Constellation Financial Software. SAFE Security. Athena Intel. Spark Inventory. Bueno. These are not Hatica's customers -- they are Hatica's customers' customers, and their login credentials were sitting in a plaintext database because Posium's architecture required storing them unencrypted for automated browser testing. Anyone with access to this database can log into these applications as these users. Which is exactly what we did.
The database also contained 696 AI chat conversations -- complete records of Posium's AI test planning sessions with customer application URLs, test scenarios, and internal state for apps at demo.safeone.io, homegate.ch, and various customer staging environments. And 6 active session tokens at time of extraction, including one for sjoshi@hatica.io (Sachin Joshi, Hatica co-founder) valid as an admin session on qakit.posium.ai.
134,270 JIRA ISSUES: THE CUSTOMER INTELLIGENCE TROVE
The CTO's Jira API token -- belonging to hsingh@hatica.io (Haritabh Singh) -- gave us access to hatica.atlassian.net: 19 projects, 134,270 issues, 122 Jira users.
The Customer Success project alone identifies 40+ enterprise customers by name, with support ticket histories, integration configurations, and employee contact information:
Hotstar (Disney+) -- 33 issues. Employee emails: soham.majumdar@, abhishek.awale@, sundarapandyan.sa@, nitya.tiwari@, amarnath@.
Viacom18 (Paramount/Reliance) -- 15 issues. Ticket CS-185 contains a telling admission: 'We are contractually obligated to NOT show any individual level data.' The contractual data handling restriction that Hatica documented in plaintext Jira tickets -- the same Jira instance we accessed trivially.
PayPay Corporation (Japan) -- 9 issues. Truecaller -- 7 issues. ShareChat -- 13 issues. Moglix -- 25 issues. EPAM Systems -- 1 issue. SwissMarketplace Group -- 16 employee emails extracted.
175 unique email addresses across 73 company domains. A spear-phishing campaign's worth of verified corporate contacts, all sourced from the engineering management platform those companies trusted with their data.
The Compliance project -- 22 issues -- documents Hatica's own Vanta security audit failures:
- 10 EC2 instances with public SSH access (including 'security-monitor-01' -- the irony writes itself)
- 20+ S3 buckets without Block Public Access enabled
- Critical Dependabot vulnerabilities left unpatched: arbitrary code execution in Babel, SSRF in parse-url, authorisation bypass in parse-path
This is a company that markets itself as SOC 2 Type II compliant.
THE GCP INFRASTRUCTURE
The github-ci@posium.iam.gserviceaccount.com service account gave us:
- 8 Cloud Run services in us-central1, all deployed by the compromised CI account
- Full container registry access: 6 Docker images pulled (platform-api, qakit-api, qakit-smtp, reporter-api, runner, webapp)
- 5 Wasabi S3 buckets: 6,243 files totalling 5.1 GB of test screenshots, Playwright trace files, and test case source code containing customer credentials
A LOT OF LETTERS TO SEND
The notification obligations here are extraordinary.
DixiApp/PyjamaHR Slack customers: 4,700
Mailgun customer email domains: 101
Hatica engineering metrics customers (Jira): 40+
Posium/QAKit customers (credentials): 11+
Total: 4,850+
GDPR applies to Hatica's EU customers -- NS TOPAAS (Dutch National Railways), Doctissimo (France), SwissMarketplace Group, multiple others. Japan's APPI covers PayPay Corporation. India's DPDP Act covers Hotstar, ShareChat, Moglix, and dozens more. The estimated fine exposure under GDPR alone could be as high as 20 million EUR or 4% of annual turnover -- though for a company generating less than $3 million annually, the reputational damage will kill them long before the fines arrive. To say nothing of the lawsuits coming their way.
TO HATICA, AND TO NAOMI CHOPRA AND HARITABH SINGH
You built a platform that asks engineering teams to hand over their most sensitive operations data -- commit histories, code review patterns, meeting schedules, productivity metrics -- and you stored the keys to all of it in plaintext environment files committed to GitHub repositories. Your token signing key is 'hustleandwin'. Your credential encryption key -- the one that protects the OAuth tokens your customers entrusted to you -- was sitting in a values.yaml file alongside a NextAuth secret that is literally the word 'secret'.
You claim to be SOC 2 Type II compliant. Your own Jira compliance project documents 10 EC2 instances with public SSH, 20 S3 buckets without public access blocks, and critical code execution vulnerabilities left unpatched. Your security monitor server -- 'security-monitor-01' -- had its SSH port open to the internet.
You asked 600 companies to trust you with the inner workings of their engineering teams. You asked 4,700 companies to install a Slack bot that could enumerate their employees. You asked JP Morgan, BrowserStack, and GE Healthcare to store test credentials in your platform. And you protected all of it with a GitHub token that had 'delete_repo' scope. Yes, we could have deleted the entirety of your Github org, but we are not vandals; we prefer to let your own actions (and lack thereof) do the damage. Although that would have certainly been one way to sanitise a codebase leaking so many credentials.
You could have prevented this every step of the way. You could have patched your vulnerable servers; you could have sanitised your repos of hardcoded credentials; you could have taken us up on our very reasonable offer. But you did none of these things.
We hope you like writing breach notifications as much as we do.
---
THE DATA
The structure is as follows:
Source Code (75 repos, full git history -- in 'haticahq' archive within main archive):
- haticahq/astro/ -- Main backend monorepo (17 services)
- haticahq/posium-core/ -- QA testing platform monorepo (13 apps, 18 packages)
- haticahq/dixiapp-backend/ -- Legacy Django backend with production env files
- haticahq/dixiapp-frontend/ -- Legacy React frontend
- haticahq/helm-charts/ -- 35 Kubernetes Helm charts
- haticahq/ranch/ -- Kubernetes kustomize configs
- haticahq/onprem/ -- On-premises deployment with plaintext secrets
- 68 additional repositories (conduit, mason, milo, fusion, cube, events-api, amplify-notify, growth-monitor, qakit, posium-*, BI dashboards, monitoring tools, and more)
Production Databases:
- dixi_app/dixi_app_FULL.json -- 5.7 GB complete DixiApp production database (85 tables, 140,472+ rows, 4,700 Slack bot tokens)
- alloydb_dumps/posium_all_tables.json -- 16 MB Posium AlloyDB dump (119 users, 497 sessions, 78 project variables, 696 AI chats)
- alloydb_dumps/qakit_db_complete.json -- 675 KB QAKit database (92 orgs, 246 projects, 65 inboxes, 306 captured emails)
Jira:
- hatica_jira_full_dump/ -- 134,270 issues across 19 projects, 175 customer emails, Vanta audit failures
Cloud Storage:
- wasabi_reporter/ -- 311 files, 373 MB (test results)
- wasabi_reporter-dev/ -- 4,143 files, 4.5 GB (dev test results)
- wasabi_test-cases/ -- 170 files with customer credentials
- wasabi_f0-reporter-dev/ -- 1,598 files, 310 MB
- wasabi_cosium-reporter-dev/ -- 21 files
Docker Images:
- platform-api, qakit-api, qakit-smtp, reporter-api, runner, webapp -- 2.5 GB total
Infrastructure:
- GCP enumeration data (service accounts, Cloud Run services) and API key enumeration data
- Redis dumps (production and cloud)
- Mailgun domain data (101+ customer subdomains)
- Statsig configuration
- PostHog feature flags
If you are a customer of Hatica, DixiApp, PyjamaHR, or Posium/QAKit, you should assume your integration credentials have been compromised. Rotate your GitHub tokens, Jira API keys, and Slack OAuth grants immediately.
We suggest giving them a call letting them know how much you appreciate their security posture putting your entire organisation at risk.
