Your finance director runs the monthly reconciliation the way she always does. She pulls the donation report out of the website, pulls the settlement report out of the processor, and lines them up. Most months they agree, and when they do not it is a timing difference at the month boundary. She has never had reason to ask which of the two documents is telling the truth.
A Drupal security advisory published on August 26 is a good reason to ask. It describes a specific way a website can record a payment that the processor never actually took, and the reason it is worth reading even if you are not affected is that it inverts an assumption most organizations make without noticing.
What the Advisory Says
SA-CONTRIB-2026-106 covers the Commerce CyberSource module for Drupal, catalogued as CVE-2026-81159 and rated moderately critical, 11 out of 25 on the Drupal scale. Versions before 1.10.0 are affected and the fix is in 8.x-1.10.
The module does not properly validate the integrity of payment data coming back from CyberSource. In the advisory's own description, a timing attack could allow an attacker to trick the site into registering that payment has been received even if it has not. The issue is limited to the Secure Acceptance Hosted Checkout integration.
Note which direction that failure runs. Most payment bugs cost you money by breaking a transaction that should have worked. This one does the opposite: it produces a record of money you never received. Nothing looks broken. The order completes, the receipt goes out, the thank-you page renders, and the number lands in your report.
Who This Actually Affects
Narrowly, very few associations. Three things all have to be true, and you can rule yourself out on the first one:
- You run Drupal Commerce. If your dues and donations go through WordPress, a hosted processor page, or your AMS, this advisory is not about you.
- You use the Commerce CyberSource module. CyberSource is a Visa product common in higher education and larger institutions, and much less common in mid-sized associations.
- You use Secure Acceptance Hosted Checkout specifically. The advisory scopes itself to that one integration. Other CyberSource connection methods are not in scope.
If all three are true, patching is not the whole job. Update to 8.x-1.10, then reconcile recent transactions against the processor rather than against your own order records. The failure mode here is a false positive on your side, which means your site cannot be used to detect it. Only the processor's settlement data can.
The Part That Applies to Everyone Else
The reason to read a narrow advisory is usually the assumption it exposes, and this one exposes a good one: an association's website is not a system of record for money. It is a system of convenience that reports what it believes happened.
The website records an intention. The processor records a fact. Between those two there is a network call that can fail, be delayed, be retried, be spoofed, or in this case be timed in a way that produces the wrong answer. In normal operation the two agree often enough that people stop treating them as separate things.
This is also why the failure survives an audit. If your monthly reporting is built from the website's own numbers, and your reconciliation compares the website to itself in a different format, an inflated figure passes every check you run. It surfaces at the annual audit, or when a board member asks why the deposits do not match the campaign total, which is a considerably worse place to find it.
What Reconciliation Should Actually Compare
Most associations reconcile, but reconcile the wrong pair of documents. Four things worth confirming about how yours works, none of which require a developer:
- Which document is the source of truth? It should be the processor's settlement report, not the website's order list. If your process starts from the website and checks the processor for exceptions, that is backwards.
- Are failed and pending transactions visible at all? Some site-side reports only show completed orders, which means a discrepancy shows up as an absence rather than an error. Absences are hard to notice.
- Who reconciles, and how often? Monthly is normal. During a year-end appeal or a conference registration window, monthly means a problem can run for four weeks against your highest volume of the year.
- Does anybody compare the totals to the bank? Processor to bank is the last link, and it is the one that catches everything the first two comparisons miss.
How You Would Know It Had Already Happened
Patching stops it recurring. It does not tell you whether it already occurred, and that is the question a board will ask. Three signals, in the order they are worth checking:
- Completed orders with no matching settlement. Pull the last ninety days from the processor and from the site, and look for orders the site calls complete that never appear on a settlement report. One or two at a month boundary is timing. A cluster is not.
- Receipts sent for amounts that never cleared. If your site emails a receipt on order completion rather than on settlement confirmation, a false positive has already gone out over your name. That is a donor relations problem as much as an accounting one, and it is worth knowing before the donor raises it.
- Campaign totals that outran the deposits. Any public-facing thermometer or annual report figure built from site data rather than settlement data inherits the error and repeats it in print.
The Wider Batch, Briefly
This advisory was one of a set published on August 26. Another worth knowing about is SA-CONTRIB-2026-113 for the Entity API module, which does not correctly apply access controls for JSON:API entity collection endpoints. It only triggers when Entity API and JSON:API are both enabled, which is a common configuration on a site feeding a mobile app or a headless front end. The fix is 8.x-1.8, and the practical question is whether member data is enumerable through an endpoint nobody remembers turning on.
None of the batch was marked unsupported. That matters more than the individual ratings. An unsupported module means the fix is to remove it, which is a project. A supported one means the fix is to update it, which is an afternoon.
If You Are Not on Drupal
Then the specific advisory is not yours and there is nothing to patch. The reconciliation question is still worth ten minutes, because it is not a Drupal question. Any platform where your site writes its own record of a payment has the same structural gap, and the only thing that closes it is comparing against the processor rather than against yourself.
Have Us Check the Money Path
Tell us what your donation and dues pages run on and which processor sits behind them. You will get back a written page: whether any module or plugin in that path has an open advisory, which document your current reconciliation actually treats as authoritative, where failed and pending transactions are visible, and whether anyone is comparing processor totals to the bank. If the answer is that your setup is sound and your reconciliation starts in the right place, that is the page, and it is a useful thing to hand an auditor.