Fakturownia Breach and the Case for Invoice Bug Bounties

An invoice software bug bounty pays researchers for verified flaws that could expose customer data, compromise integrations, or change financial records. It needs a vulnerability disclosure policy first: a safe testing scope, a reporting channel, and people who will assess and fix what comes in. Fakturownia’s 29 September breach notice shows why that path matters for a platform holding other businesses’ accounts and documents. There is no public evidence that a bounty would have prevented this intrusion.

What has Fakturownia confirmed?

Fakturownia says it detected unauthorized access to its servers on 28 September 2026. Its public notice, dated the next day, says an unauthorized person exploited a flaw in its system and had visibility into user account data, counterparties, and documents generated through the platform. The notice gives the detection date, not the date the intrusion began. It does not explain the flaw or establish how much data left the system.

The company says possible access covered account data for all its users, their counterparties, and invoices issued before 2023. Its list includes password hashes, session tokens, Fakturownia-issued API and integration tokens, bank account and payment details, some invoice data, and application keys and system passwords. Password hashes are not the users’ plaintext passwords, but the possible exposure of access tokens and application secrets demands its own response. Fakturownia says it has blocked the unauthorized access, started rotating keys and passwords, launched new servers, and reported the incident to CBZC, CERT Polska, and Poland’s data protection authority. Its investigation is still underway.

Fakturownia also says its current findings show no compromise of KSeF certificates, data stored in its integrations, payment-card data, or invoices issued after 2023. The notice does not clearly address invoices issued during 2023. Its reference to potentially exposed Fakturownia-issued integration tokens concerns a different data class from data stored inside external integrations; the two statements should not be collapsed into one.

Zaufana Trzecia Strona reports that a person claiming responsibility said they took 6 TB of invoices. That is an attacker claim, not a volume Fakturownia has confirmed. The publication also relays a proposed attack method, but the company’s notice confirms only that a system flaw was exploited. A detailed exploit chain, the attacker’s identity, and the volume taken remain unverified in the public record.

Why does one invoicing flaw reach beyond one customer?

An invoice vendor is a hub for several parties’ data. A customer’s account may contain staff access, counterparties’ names and contact details, bank accounts, invoice lines, and the credentials that connect accounting, commerce, and payment systems. A problem in the vendor’s own platform can therefore create work for many customer companies, their finance teams, and people who never opened an account with that vendor.

That is why a report about cross-account access deserves different handling from a cosmetic bug. If one researcher-owned test account can read an invoice from a separate test account, the vendor needs an owner who can reproduce the finding, assess whether the boundary is broken elsewhere, fix it, and communicate with the finder. The researcher must be able to prove the issue using accounts and documents they control, without opening a real customer’s invoice. OWASP’s API Security Top 10 identifies broken object authorization and authentication as separate API risks; both belong in an invoice platform’s testing plan.

The same applies to access tokens and money-moving fields. A report might show that a token survives revocation, a user can act outside their assigned account, or a bank-account change bypasses a safeguard. These are examples of potential bounty scope, not findings about the Fakturownia attack. External testing can help find defects in reachable product surfaces; it cannot replace secure design, code review, least-privilege access, monitoring, or incident response.

What do the older bug-bounty comments actually show?

The public trail raises a fair question about how security reports reach product owners. Fakturownia’s suggestion forum index shows a 2016 question asking whether the company planned a bug bounty. We could not verify the linked thread’s answer. Its public security page tells visitors how to flag suspicious invoices, phishing, and login-page concerns, but the page we reviewed does not set out a vulnerability-testing scope, safe-harbor terms, response target, or reward rules. That observation does not establish whether Fakturownia has a private security-reporting process.

In LinkedIn comments shared with us after the incident, two practitioners say they had raised issues with Fakturownia in earlier years. One says some proof-of-concept bugs concerned the vendor’s revenue rather than customer-data security. We have not seen the reports, the company’s replies, or a link between any of those claims and this breach. The comments raise a program-design question, not evidence that a reported vulnerability was ignored and later exploited.

What should happen when a finder reports a practical abuse case that does not fit a narrow list of technical vulnerabilities? A billing or discount loophole is not automatically a security defect. It still needs a route to a person who can assess impact, decide whether it belongs in the bounty, and give the finder an answer. A vendor that silently drops such a report loses a useful signal, even when its security bounty does not pay for that class of issue.

Where should an invoice bug report go?

A useful program specifies the next decision, not just an email address. NIST’s disclosure guidance recommends a formal process to receive, assess, handle, and communicate about reports. The security team can own intake, but it must be able to route findings to the engineering, finance, or product owner who can act on them.

For every row, the finder needs an acknowledgement, a status update, and a reasoned decision. A valid report should not disappear because one team calls it a product issue and another calls it a security issue. The vendor can choose different reward rules for each class, but it should publish the boundary and own the handoff.

What should the vendor publish before offering rewards?

Publish a vulnerability disclosure policy (VDP) with an easy-to-find contact, the vendor-owned app and API scope, safe-harbor terms for good-faith testing, response expectations, and a route for uncertain cases. A security.txt file can point researchers to the contact and policy; the file itself does not authorize testing. The VDP setup guide covers the broader setup.

For invoice software, provide two separate researcher-owned test accounts and synthetic documents. Several companies can sit inside a single account, so two company records alone may not test the account boundary. Require researchers to stop if they encounter real invoices, bank details, or credentials, then report the minimum redacted evidence. Prohibit bulk export, payment changes, destructive tests, social engineering, and load testing. Name only systems the vendor owns or is authorized to have tested. Visma’s current policy illustrates a broad reporting route with safe-harbor rules and a narrower paid bounty for listed assets.

Then fund a scoped paid bounty when the team can validate additional reports, fix accepted issues, and honor its reward decisions. OWASP’s disclosure guidance warns that a bounty increases both submissions and the work needed to process them. Pay for demonstrated impact, not for the label attached to a report; publish ranges and duplicate rules so a finder knows what to expect. The reward-tier guide explains the mechanics.

No public source shows that an outside researcher found Fakturownia’s exploited flaw first, could have tested it safely, or tried to report it. A paid program cannot be credited with preventing this incident. It can give future findings a better chance to reach an accountable team before a criminal actor uses them.

What should Fakturownia customers do and ask now?

As of its 29 September notice, Fakturownia recommends changing the account password and any reused passwords, securing the linked email account, enabling two-factor authentication, and checking the bank-account number and user list in account settings. It also warns about messages and calls that impersonate banks, authorities, the company, or counterparties. Those are the company’s current public recommendations while it determines whom to notify. Ask Fakturownia directly about the status of any session, API, or integration token you use; the public notice lists those as potentially accessible but does not give a complete customer rotation procedure.

Then ask for the vendor’s disclosure process. Can an unaffiliated researcher find a security contact without logging in? Does the policy authorize testing of vendor-owned systems while protecting customer data? Will a report about a cross-account invoice, token, bank detail, or billing rule reach someone who can fix it and answer the finder? These questions apply to accounting systems, billing platforms, and our own category of KSeF-related software. The safe-harbor article covers authorization language; the scope guide covers vendor-owned assets and customer systems.

How can Kit handle the report-to-decision path?

Kit helps a vendor publish a scoped disclosure program and a discoverable security.txt contact. Researchers can submit reports through the portal; the team can assign an owner, track response targets, discuss findings, and record an optional bounty decision. Kit tracks the payment handoff, while the vendor moves the money through its own provider.

The first useful test is simple: submit a synthetic cross-account report and follow it from receipt to an engineering decision and a reply. That checks whether a real finder will be heard. Kit organizes that path; the vendor still has to investigate, fix the flaw, and protect its customers.