Polish Logistics Giant InPost Allegedly Breached with 2 Million Employee Records Exposed

[enaph]

Content source

https://darkwebinformer.com/polish-logistics-giant-inpost-allegedly-breached-with-2-million-employee-records-exposed/

A threat actor using the handle "aiyewumi" claims to have breached the database of InPost, described as a major Polish logistics company specializing in postal and parcel delivery services. The exposed data is reportedly in SQL format and approximately 220MB in size, containing around 2 million employee records.

• Company Description: InPost is a big Polish logistics company
• File Type: SQL database
• Total Records: Approximately 2 million records
• File Size: 220MB
• Employee First Names: Full employee first name data
• Employee Last Names: Full employee last name data
• Employee Emails: Corporate email addresses
• Employee IDs: Internal employee identification numbers
• Employee Access Codes: System access codes and credentials
• Employee Addresses: Physical address information
• Employee Passwords: Password data (likely hashed)
• Employee IP Addresses: IP address logs
• Case IDs: Internal case identification numbers
• Dates: Timestamp and date information
• Branch Information: Branch location and assignment data
• Status Information: Employee or case status indicators
• Sample Data: SQL data visible in screenshot showing InPost locations (Centrala, Gdynia, Katowice, etc.)
• Post Status: Posted 2 hours ago (as of alert time)
• Access: Hidden content requiring payment of 8 points to unlock

 

[Bot]

Claims like this (a dark-web/forum post + a screenshot) are not proof of a real breach on their own. They are often exaggerated, recycled from older leaks, or mixed with unrelated data. That said, because the post alleges “access codes/credentials” and “passwords,” it should be treated as a potentially serious incident until disproven.

Credibility / red flags to note

• “~2 million employee records” is a very large number for employees; threat actors frequently label datasets loosely. This doesn’t confirm anything either way, but it’s a common inconsistency in breach ads.
• A screenshot of SQL text is easy to fabricate and is not a reliable validation method.
• The “pay points to unlock” model incentivizes hype and reposts.

What you should NOT do

• Do not pay to unlock, buy, download, or share the dataset. That can create legal risk and also increases victim harm.
• Do not attempt to “test” credentials from the post against any systems.

If you are on the defender side (InPost / IT / SOC / vendor)

• Treat as an external leak allegation: start an incident intake ticket and preserve the evidence (screenshots, post time, handle, forum name/URL) for internal tracking.
• Validate safely using internal sources: look for unusual database export activity, large SQL dumps, abnormal queries, new admin accounts, and exfil indicators (egress spikes) around the claimed timeframe.
• Immediately rotate potentially exposed secrets: service account passwords, API keys, DB creds, VPN creds, and any “access codes” type secrets; enforce MFA where possible.
• If corporate emails are involved, watch for targeted phishing and password-spraying attempts; consider temporarily tightening conditional access and rate-limiting auth attempts.
• Prepare for GDPR/notification workflows if evidence supports a real leak (legal/compliance should drive timelines and scope).

If you are an employee (or think you might be affected)

• Change your corporate password (and any personal passwords reused from work) and enable MFA everywhere it’s available.
• Be extra cautious with “HR/IT/security” emails and password reset prompts over the next days; verify requests via known internal channels.
• Monitor accounts for unusual login alerts; report anything suspicious to your IT/security team immediately.

Where to report / escalate

• If you believe this is real and you can identify the forum/post, report it to InPost through their official security/contact channels (do not include or forward stolen data).
• For Poland, escalation may also involve the appropriate national CSIRT (for example, CSIRT NASK) via their official reporting process.
• If this was posted on MalwareTips as an “alert,” using the forum report function can help staff handle anything that crosses into sharing illegal content.

Bottom line: treat the post as an unverified claim, don’t engage with the paid “hidden content,” and focus on safe validation/containment steps and user protection (credential hygiene + phishing defense).