A seemingly "small" flaw in FOSSBilling can translate into real financial damage for businesses that invoice via PayPal IPN. The vulnerability, CVE-2026-43928, concerns the PayPalEmail and allows customers to pay invoices with a slightly lower amount, while the system considers them fully paid, if version 0.8.0.
According to the security advisory on GitHub, the mechanism that processes PayPal IPN callbacks credits the amount declared in the mc_gross to the customer's account, without verifying it against the total amount of the invoice.
See also: PayPal and Apple Abuse for DKIM Replay Attacks
How does PayPal IPN underpayment work?
The problem occurs when an installation uses the PayPalEmail adapter for payments and relies on the PayPal IPN to “lock” an invoice as paid. The code receives the update from PayPal, but instead of comparing the transaction amount to the invoice amount, it records the payment based on the mc_gross that comes in the callback.
The situation is exacerbated by a computational tolerance (epsilon) of approximately $0.05 in the logic that reconciles invoices and payments. Thus, a customer can underpay an invoice by up to approximately $0.04 per transaction and still have the system mark it as fully paid, as described in the advisory (GHSA-xjc6-g382-h942).
Who is affected and why it is not "trivial"
According to the same source, versions up to 0.7.2, while the fix comes in 0.8.0. While the discrepancy is small, in environments with high transaction volume, the scenario can lead to cumulative revenue loss, especially for services with recurring billing or subscriptions.
It is worth noting that the PayPal IPN authenticity check does not "catch" the issue: the signature may be valid for the amount sent, so the problem is clearly in the reconciliation logic and not in some obvious error in communication with PayPal.
See also: Phishing campaign steals PayPal accounts
What should administrators do?
The recommended solution is to upgrade to FOSSBilling 0.8.0 or later. The advisory also states that there is no effective workaround without modifying the code, making updating the platform the safest option.
Until the upgrade is complete, the SecNews technical team recommends a practical immediate defense measure: monitoring IPN transactions for cases where the amount does not match the invoice total and manually checking for suspicious payments or credits.
For organizations that base their revenue stream on subscriptions, it’s also worth checking the logs retrospectively for small discrepancies per invoice. Even if the amount is a few cents, the repeatability can turn the scenario into a “silent” revenue leak over time.
See also: Invoicely: Over 178,000 customer data files exposed
In practice, the missing check is simple: the application must match each IPN callback to the specific invoice and confirm that the amount paid covers the total (plus any taxes/fees) before returning a “paid” status. Without this check, the system may accept small discrepancies as “within tolerance” and close a debt prematurely.
For teams that want extra control, it’s helpful to set alerts when payments with an unusual pattern are detected (e.g. consistently a few cents under total) or when customer credits don’t match actual payments. This reduces the chance of the issue going unnoticed, even before the upgrade.
🔒 Protect your privacy with Proton VPN
Swiss VPN from the creators of Proton Mail — strict no-logs policy, strong encryption, and built-in NetShield that blocks ads, trackers, & malware.
- ✔ No-logs, based in Switzerland (except 14-Eyes)
- ✔ NetShield: blocks ads, trackers & malicious domains
- ✔ Covers all devices — free version available
The link is an affiliate link — SecNews may receive a commission at no additional cost to you. It does not affect the independence of our article writing.
Why upgrading is a priority
This vulnerability is not a typical data leakage or RCE hack, but it directly impacts the integrity of billing and accounting. In any case, updating to version 0.8.0 and confirming that the payment process accurately checks invoice amounts is the minimum that needs to be done before the issue is exploited systematically.
For more technical details, administrators can refer to the full advisory on GitHub (GHSA-xjc6-g382-h942) and confirm that their environment is not running an older version.
