[{"data":1,"prerenderedAt":245},["ShallowReactive",2],{"seo-verification":3,"blog-drupal-commerce-cve-2026-118539-update-and-audit-orders-en":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-drupal-commerce-cve-2026-118539-update-and-audit-orders-en",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":30,"intro":33,"sections":34,"ctaTitle":191,"ctaBody":192,"ctaButton":193,"ctaUrl":194,"relatedPosts":195},556,"drupal-commerce-cve-2026-118539-update-and-audit-orders",{"fr":12,"en":10,"ar":13,"es":14},"drupal-commerce-core-cve-2026-118539-sa-contrib-2026-254-mettre-a-jour","ثغرة-drupal-commerce-cve-2026-118539-التحديث-وتدقيق-الطلبات","drupal-commerce-cve-2026-118539-actualizar-y-auditar-pedidos","Drupal Commerce CVE-2026-118539: patch and audit orders","Commerce Core flaw under exploitation, advisory SA-CONTRIB-2026-254: find affected versions, move to 3.3.13 or 8.x-2.41, then audit your orders.",10,0,false,"2026-11-01T00:00:00+00:00","2026-11-01T14:14:31+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},8,"Security & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fdrupal-commerce-core-cve-2026-118539-sa-contrib-2026-254-mettre-a-jour-poster.svg","Advisory SA-CONTRIB-2026-254, published on October 28, 2026, describes an access bypass in Commerce Core, the module that runs the checkout of many Drupal shops. It requires no authentication, and drupal.org states it is being exploited in the wild. Fixing the version is not enough: an order altered before the patch stays in the database. For an agency hosting several shops, the question is twofold: which ones are affected, and which one has already been abused. Here is the procedure, environment by environment, with an order audit to hand to the client.",[35,39,74,77,96,99,120,123,149,167,171,182,185,188],{"type":36,"title":37,"body":38},"h2","The flaw in one paragraph, the rest is procedure","Advisory SA-CONTRIB-2026-254 concerns the Commerce Core module (`drupal\u002Fcommerce`). Drupal.org rates it \"Highly critical\", 21 out of 25, and describes an access bypass: the module does not sufficiently protect certain routes and certain entity fields. The advisory lists the required authentication level as \"all\u002Fanonymous\" and states that the flaw may have financial consequences for the vendor. It also states that it is being exploited in the wild.\n\nThe advisory names neither the routes nor the fields concerned. We therefore infer nothing: no list of paths to block, no signature to look for in the logs. The identifier CVE-2026-118539 is taken from the advisory page; we have not cross-checked it against the NVD database, so cite it as \"the identifier published by the advisory\" until that check is done.",{"type":40,"title":41,"headers":42,"rows":46},"comparison","Reference table: branch, affected version, fixed version",[43,44,45],"Your situation","Status according to the advisory","Action",[47,51,54,58,62,66,70],[48,49,50],"Commerce 3.x, from 3.0.0 up to before 3.3.13","Vulnerable","Move to 3.3.13 or later",[52,49,53],"Commerce 2.x (8.x-2.x), before 8.x-2.41","Move to 8.x-2.41 or later",[55,56,57],"Commerce 3.3.13 or 8.x-2.41 already installed","Fixed","Still audit the orders placed before the update",[59,60,61],"Drupal ^10.3 or 11","Branch 3.x listed as compatible","Update within the 3.x branch",[63,64,65],"Drupal ^9.3 or ^10","Branch 2.x listed as compatible","Update within the 2.x branch, without switching branch at the same time",[67,68,69],"Module absent from `composer.lock`","Outside the scope of this advisory","Record the absence in the inventory",[71,72,73],"Shop without Composer access or code copied by hand","Unknown version","Find the version before drawing any conclusion",{"type":36,"title":75,"body":76},"Why fixing is not enough","The advisory says it in plain words: sites must audit their orders, because the flaw is being exploited. A shop moved to 3.3.13 today may have been visited before. The update closes the access; it does not put right an order whose amount, status or payment state was altered. The advisory does not say since when the exploitation has been going on: choose a wide audit window, write it in the file, and do not shrink it to the day of the update.\n\nThen comes a mundane obstacle: without a central inventory, nobody knows which shops embed Commerce, or on which branch. The inventory method is the one used for a WordPress plugin flaw, described in \u003Ca href=\"\u002Fen\u002Fblog\u002Fbricksforge-cve-2026-85097-wordpress-update\">our Bricksforge guide\u003C\u002Fa>. The order of work is therefore: inventory, backup, update, audit, dated proof. The shops that take the most payments go first.",{"type":78,"title":79,"steps":80},"steps","Inventory the Commerce version on every shop",[81,84,87,90,93],{"title":82,"body":83},"Read the version with Composer","`cd \u002Fvar\u002Fwww\u002Fboutique-client`\n`composer show drupal\u002Fcommerce`\nThe command prints the installed version. For the 2.x branch, drupal.org speaks of 8.x-2.41; Composer shows the number without the 8.x prefix. Compare the number, not the string. The path is an example: adapt it to your hosting.",{"title":85,"body":86},"Cross-check with Drush","`drush pm:list --type=module --status=enabled --filter=commerce`\nThe list shows whether Commerce is enabled and in which version. A site may carry the code without the module being enabled: note it, because the situation changes if someone enables it later.",{"title":88,"body":89},"Read the lock file rather than the folder","`grep -A1 '\"name\": \"drupal\u002Fcommerce\"' composer.lock`\nThe `composer.lock` file tells what is really installed, without starting Drupal. It is the safest reading on a shop you do not want to stress during the audit.",{"title":91,"body":92},"Loop over every shop on a server","`find \u002Fhome -name composer.lock -not -path '*\u002Fvendor\u002F*' -exec grep -H -A1 '\"name\": \"drupal\u002Fcommerce\"' {} +`\nEach file listed contains Commerce, and the `version` line follows the name. Review the list: a forgotten test folder or a backup copy counts too.",{"title":94,"body":95},"Record the result in a table","One row per shop: client, host, path, branch, version found, Drupal version, date and time of the check. Add two columns to fill in later, \"update done\" and \"order audit done\". This table becomes the central piece of the file handed to clients.",{"type":36,"title":97,"body":98},"Back up before touching the code","A module update is hard to undo without a restore point. Before each shop: a backup of the database and the code, on storage that the update does not touch, with its date recorded in the table. On an active shop the database changes with every order: the backup fixes the state from which you can compare orders afterwards. Do not overwrite it with the next one until the audit is closed. It serves twice: to roll back, and to prove what the shop contained before the fix.",{"type":78,"title":100,"steps":101},"Update one shop",[102,105,108,111,114,117],{"title":103,"body":104},"Freeze the state","`drush sql:dump --gzip --result-file=\u002Fchemin\u002Fsauvegarde\u002Fboutique-avant.sql`\nAlso copy the project folder: code, `composer.json`, `composer.lock` and files. Note where the copy is stored in the table.",{"title":106,"body":107},"Check what the Composer constraint allows","`composer why-not drupal\u002Fcommerce 3.3.13`\nIf `composer.json` pins a version, this command names what blocks the update. A shop on 2.x stays on 2.x and aims for 8.x-2.41: switching branch is a separate project, to plan on its own.",{"title":109,"body":110},"Update the module and its dependencies","`composer update drupal\u002Fcommerce --with-dependencies`\nReview the list of changed packages before confirming: another Commerce module may move along with it.",{"title":112,"body":113},"Apply the database updates","`drush updatedb -y`\n`drush cache:rebuild`\nThe first command runs any pending schema updates, the second clears the caches.",{"title":115,"body":116},"Check the installed version","Run `composer show drupal\u002Fcommerce` again. The version must reach 3.3.13 on the 3.x branch, or the number 2.41 on the 2.x branch. Record it in the table, with the date and time.",{"title":118,"body":119},"Place a test order","On staging, or in the payment gateway's test mode, add a product to the cart, place the order and check the amount, the status and the payment. An update that breaks checkout must be noticed before the client notices it.",{"type":36,"title":121,"body":122},"One procedure per environment","The same fix is not played the same way everywhere. The following table sets, for each environment, the expected action and the proof to keep. A public staging site counts as a shop.\n\nAutomatic system updates, described in \u003Ca href=\"\u002Fen\u002Fblog\u002Fvps-automatic-security-updates-debian-ubuntu\">our guide on Debian and Ubuntu\u003C\u002Fa>, do not touch a Drupal module: that action remains the agency's.",{"type":40,"title":124,"headers":125,"rows":128},"Development, staging, production: the action and the proof",[126,45,127],"Environment","Proof to keep",[129,133,137,141,145],[130,131,132],"Production","Backup, update, `drush updatedb`, test order, then audit","Dated backup, version found, audit result",[134,135,136],"Staging reachable from the Internet","Update first if the code is identical, or protect it with a password in the meantime","Version found, protection chosen",[138,139,140],"Closed or local staging","Update and replay the test order before production","Screenshot of the test order, date",[142,143,144],"Development","Align `composer.lock` with production so the old version is not reintroduced at the next deployment","Lock file commit, version found",[146,147,148],"Restored copy or backup","Never put it back online without the update","Note in the client file",{"type":78,"title":150,"steps":151},"Audit the orders without presuming the attacker's method",[152,155,158,161,164],{"title":153,"body":154},"Set the window","Choose a wide start date and write it down. The advisory gives no start date for the exploitation: take at least the period covered by your backups and your logs, and write why.",{"title":156,"body":157},"List the orders in the window","Export the orders with their number, creation and placement dates, status, total and currency. The administration interface is enough. In the database, start by reading the column names:\n`drush sql:query \"DESCRIBE commerce_order\"`\nThe exact names depend on your version: do not assume them.",{"title":159,"body":160},"Look for internal discrepancies","For each order, compare the total with the calculation of its lines and adjustments. A total that does not match its lines, a price reduction nobody configured, or a line price different from the catalog: each discrepancy needs investigating.",{"title":162,"body":163},"Cross-check with the payment gateway","An order completed without a matching payment at the provider, or a payment whose amount differs from the total, deserves a close look. The provider's statement is authoritative for the money collected: do the cross-check on the exports, not on what the shop displays.",{"title":165,"body":166},"Look at state transitions","Spot the orders whose status changed without human action or a consistent payment: validated without going through payment, or reaching a final status within seconds. Access logs help date what happened. The advisory details no route: a search by path is a clue, never proof of absence.",{"type":168,"title":169,"body":170},"tip","What the audit does not prove","A clean audit says that no inconsistency is visible in the orders. It does not say that no request abused the flaw: the advisory speaks of routes and entity fields without naming them. Write in the report what you looked at, and what you did not look at.",{"type":172,"title":173,"items":174},"ul","If an order is inconsistent",[175,176,177,178,179,180,181],"**Delete nothing** — keep the order, its payments and the dated backup: they are the pieces of the file.","**Suspend delivery** — block shipping or access to the digital product until the payment is confirmed at the provider.","**Warn the agency's client** — your report states the order, the discrepancy found, the date and the amount concerned.","**Query the payment provider** — it holds the statement of collections; ask for the transaction detail.","**Keep the logs** — copy the access and application logs of the period before they rotate.","**Check the accounts** — if you find an account or a role nobody created, change the administration passwords and the gateway keys.","**Measure before restoring** — going back to a pre-incident backup also erases the legitimate orders placed since.",{"type":36,"title":183,"body":184},"The other Commerce advisories of the same day","On October 28, 2026, drupal.org published other advisories touching the Commerce ecosystem, numbered 255 to 265: Commerce Core, Commerce Shipping, Commerce License and Commerce Stripe. They are rated less severe than 254, and only 254 states exploitation in the wild. One of them, on Commerce Stripe, still reaches \"Critical\" (15 out of 25).\n\nDo not update only Commerce Core, then. List the Commerce packages of each shop with `composer outdated 'drupal\u002Fcommerce*'` and read each advisory on drupal.org\u002Fsecurity before deciding.",{"type":36,"title":186,"body":187},"Who holds the client relationship, and what you hand over","When a fraudulent order is found, the client calls the agency. Keep that role: the agency holds the relationship, the audit report and the decision on refund or restore. The platform holds the infrastructure: an isolated account per client, backups to restore, SSH or WHM access to update without waiting for a ticket. We do not modify a shop's application code in your place; updating Commerce remains the agency's action.\n\nHand the client a dated page: version before, version after, date and time of the update, backup reference, audit window, number of orders reviewed, discrepancies found or none, and what was not looked at. Keep the template: the next advisory on a Drupal module will follow the same sequence, with another row in the inventory. The monthly review rhythm is described in \u003Ca href=\"\u002Fen\u002Fblog\u002Fmonthly-security-audit-checklist-client-vps-agency\">the client VPS audit checklist\u003C\u002Fa>.",{"type":36,"title":189,"body":190},"The official documentation","\u003Ca href=\"https:\u002F\u002Fwww.drupal.org\u002Fsa-contrib-2026-254\">Advisory SA-CONTRIB-2026-254\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.drupal.org\u002Fsecurity\">List of security advisories\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.drupal.org\u002Fproject\u002Fcommerce\">Commerce project page\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fgetcomposer.org\u002Fdoc\u002F03-cli.md\">Composer command-line documentation\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.drush.org\u002Flatest\u002F\">Drush documentation\u003C\u002Fa>","Keep control of your clients' shops","Isolated accounts per client, backups before updates, WHM and SSH access to apply a fix without waiting, expirations and fleet visible in one place: the client relationship stays with you.","See the agency solution","\u002Fsolutions\u002Fagences",[196,214,229],{"id":197,"slug":198,"slugs":199,"title":203,"excerpt":204,"readTime":17,"views":18,"isPinned":19,"publishedAt":205,"updatedAt":206,"category":207,"categories":208,"featuredImage":30,"bgImage":31,"posterImage":210,"relatedSolution":211},525,"bricksforge-cve-2026-85097-wordpress-update",{"fr":200,"en":198,"ar":201,"es":202},"bricksforge-cve-2026-85097-wordpress-mettre-a-jour","ثغرة-bricksforge-cve-2026-85097-ووردبريس-التحديث","bricksforge-cve-2026-85097-wordpress-actualizar","Bricksforge CVE-2026-85097: update and audit your WordPress fleet","Bricksforge 3.1.8.10 fixes CVE-2026-85097, an exploited unauthenticated upload. wp-cli inventory, dropped PHP files, access logs, secrets to rotate.","2026-10-29T00:00:00+00:00","2026-10-29T15:45:55+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[209],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fbricksforge-cve-2026-85097-wordpress-mettre-a-jour-poster.svg",{"categorySlug":212,"appSlug":213},"cms-websites","wordpress",{"id":215,"slug":216,"slugs":217,"title":221,"excerpt":222,"readTime":17,"views":18,"isPinned":19,"publishedAt":223,"updatedAt":224,"category":225,"categories":226,"featuredImage":30,"bgImage":31,"posterImage":228,"relatedSolution":30},521,"monthly-security-audit-checklist-client-vps-agency",{"fr":218,"en":216,"ar":219,"es":220},"checklist-audit-securite-mensuel-vps-clients-agence","قائمة-تدقيق-أمان-vps-شهرية-للعملاء-للوكالات","auditoria-seguridad-mensual-vps-clientes-agencia-checklist","Monthly client VPS security audit: a 45-minute checklist","Seven checks to run every month on a client VPS: updates, kernel, SSH accounts, ports, certificates, backups, logs. Includes a dated one-page report.","2026-10-28T00:00:00+00:00","2026-10-29T03:10:22+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[227],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fchecklist-audit-securite-mensuel-vps-clients-agence-poster.svg",{"id":230,"slug":231,"slugs":232,"title":236,"excerpt":237,"readTime":17,"views":238,"isPinned":19,"publishedAt":239,"updatedAt":240,"category":241,"categories":242,"featuredImage":30,"bgImage":31,"posterImage":244,"relatedSolution":30},382,"vps-automatic-security-updates-debian-ubuntu",{"fr":233,"en":231,"ar":234,"es":235},"securite-vps-mises-a-jour-automatiques-debian-ubuntu","تحديثات-أمان-تلقائية-vps-debian-ubuntu","actualizaciones-seguridad-vps-debian-ubuntu","Automatic Security Updates on Debian\u002FUbuntu VPS","Configure unattended-upgrades on your Debian\u002FUbuntu VPS to automate security patches and reduce attack surface across your client fleet.",2,"2026-09-26T00:00:00+00:00","2026-09-29T14:40:42+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[243],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fsecurite-vps-mises-a-jour-automatiques-debian-ubuntu-poster.svg",1793542958195]