---
title: Black Friday Code Freeze 2026 — What to Lock, What You Must Still Patch
description: Plan a Black Friday 2026 code freeze for your store — what to lock, which security patches still ship, and a short test plan for emergency changes during peak.
source: https://pingvera.com/blog/black-friday-code-freeze-security-patches.html
---
# Black Friday Code Freeze 2026: What to Lock, What You Must Still Patch

A Black Friday code freeze is a fixed period before and during peak trading when
you stop shipping non-essential changes to the store: no new plugins or apps, no
theme changes, no checkout experiments, no platform upgrades for the sake of new
features. In 2026 Black Friday falls on 27 November and Cyber Monday on
30 November, so most stores that follow that calendar will want the freeze to
begin in early-to-mid November and the riskiest changes finished before then.

What a freeze must not do is block security fixes. Platforms and plugins keep
shipping patches through the autumn, and some of them close holes directly in
the payment path. The sensible plan is therefore not "change nothing" but
"change only through a narrow, rehearsed exception route". This article gives
you the dates, the rules, an exception test plan and the checks to run after any
change that slips through.

## At a glance

- Do the risky work now: platform upgrades, plugin updates and integration
 migrations belong in October, not in the freeze window.
- Freeze features, not security. Define in writing which fixes may still ship
 and who approves them.
- Turn off unattended auto-updates on revenue-critical sites for the freeze
 window and replace them with a daily, human-reviewed update check.
- Every emergency change gets the same short test: place a real order, confirm
 the payment, confirm the email, confirm the order count keeps moving.
- Check integrations with fixed deadlines (for example product feed APIs) before
 the freeze, because they can fail on a vendor's schedule, not yours.

## Why it matters now

Three things make October 2026 the right moment to plan the freeze rather than
improvise it in November.

**Platforms are still shipping security releases.** As of October 2026,
WooCommerce has released a major version roughly every month: 11.0.0 on
4 August, 11.1.0 on 1 September and 11.2.0 on 7 October, followed by 11.2.1 on
9 October. The 11.2.0 release notes state that it "includes security fixes"
and ask merchants to update all stores; it also requires a database update.
A release with a database migration is exactly the kind of change you want
tested and live well before peak, not applied on the morning of Black Friday.

**Payment plugins get vulnerabilities too.** On 21 September 2026,
CVE-2026-92400 was published for the Payment Gateway for PayPal on WooCommerce
plugin before version 9.2.1. According to the advisory, the plugin did not
verify that a payment notification came from the store's configured payment
environment or was paid to the store's own merchant account before marking an
order complete, which allowed an unauthenticated user to mark their own order as
paid using a genuine transaction from a sandbox they controlled. It is rated
medium (CVSS 5.3), but the effect is direct: orders that look paid and are not.
If a fix like this lands in the middle of your freeze, you need a way to ship
it the same day.

**Some integrations break on the vendor's calendar.** Google's Content API for
Shopping was sunset on 18 August 2026. Since 1 September 2026, requests without
an approved extension intermittently fail with `HTTP 410 Gone`, and Google says
all endpoints will be turned down in early 2027. A feed app or custom script
still on the old API may work most of the time and fail some of the time, which
is the hardest kind of failure to notice during a busy week.

On WordPress, plugin and theme auto-updates can be enabled per plugin and, by
default, run twice a day. That is a good security habit for most of the year.
During a freeze it means a third party can change your checkout code at any
hour without anyone on your side testing it.

## Step-by-step: set up the freeze this week

1. **Pick the dates and publish them.** Write down the freeze start, the end
 (for example the Wednesday after Cyber Monday) and the time zone. Share it
 with everyone who can change the store: in-house staff, agencies, freelancers,
 app vendors with access.
2. **Finish the risky work first.** Before the freeze, apply pending platform
 and plugin updates in staging, test them, then deploy to production with at
 least one or two weeks of normal trading afterwards to surface problems.
 Treat any release that includes a database update as high risk.
3. **Inventory what can change without you.** List auto-updating plugins and
 themes, SaaS apps that update themselves, tag managers, A/B testing tools,
 payment provider settings, shipping rate tables and feed tools. Each is a
 way the store can change during a "frozen" period.
4. **Switch auto-updates to reviewed updates.** On revenue-critical WordPress
 sites, disable auto-updates for the freeze window on the Plugins screen and
 assign a person to review available updates once a day. Note which plugins
 touch checkout, payments, tax, shipping and order emails.
5. **Check fixed-deadline integrations.** Confirm your feed tool or script uses
 a supported API (for Google, the Merchant API), and review similar notices
 from your payment, shipping and email providers.
6. **Define the exception route.** Decide what qualifies (see the table below),
 who approves, who deploys, and the test that must pass. Keep it to two
 people so it can work at 22:00 on a Saturday.
7. **Prepare rollback.** Take a fresh backup before the freeze and confirm you
 can restore it. Keep the previous version of every critical plugin at hand.
8. **Record a baseline.** Note normal order volume per hour, payment success
 rate and email delivery for recent weeks, so that during the freeze "is this
 normal?" has an answer.

## What to lock and what to allow

Two notes on the table. First, a security fix is not automatically urgent:
read the advisory, check whether the vulnerable feature is enabled on your
store, and decide. Second, if you cannot patch safely, temporary mitigation
(disabling a feature or a non-essential plugin) is also a change and goes
through the same route.

## Copyable artefact: emergency change test plan

Paste this into your ticket or chat before deploying anything during the
freeze.

EMERGENCY CHANGE DURING FREEZE

Change: [plugin/app/platform + old version -> new version]
Reason: [advisory link / incident link]
Exploitable on this store? [yes/no + why]
Approved by: [name] Deployed by: [name]
Backup taken: [time, location] Rollback steps: [link or 3 lines]
Deploy time: [time + time zone]

BEFORE DEPLOY (staging, if available)
[ ] Change applied on staging, no PHP/JS errors in logs
[ ] Test order with each payment method used in production
[ ] Database update (if any) completed without errors

AFTER DEPLOY (production, within 15 minutes)
[ ] Home, category, product, cart and checkout pages load
[ ] One real low-value order placed and paid with the main payment method
[ ] Order shows correct status in admin and at the payment provider
[ ] Order confirmation email received in an external inbox
[ ] Pages still indexable (no unexpected noindex), no unexpected redirects
[ ] Product feed still updating (last successful fetch/sync time checked)

WATCH (next 2 hours)
[ ] Orders per hour within normal range for this time of day
[ ] Failed/pending order rate not rising
[ ] Refund the test order; note the result in this ticket

Worked scenario (illustrative)
The following is an illustrative example, not a real customer case.

A store selling homeware runs WooCommerce with a third-party PayPal gateway
plugin. The agency maintaining it freezes the site on 13 November. On a
Thursday evening during the freeze, an advisory is published for the gateway
plugin, describing a way to mark unpaid orders as paid.

The technical lead reads the advisory and confirms that the store uses the
affected payment method, so the fix qualifies for the exception route. The
owner approves by message. The lead takes a backup, applies the update on
staging, places a test order, then deploys to production at 20:10. At 20:20 a
real low-value order goes through; the order status in the admin matches the
payment provider, and the confirmation email arrives in an external mailbox.

Over the next two hours orders per hour stay within the store's usual evening
range. The test order is refunded and the ticket closed. Total effort: under an
hour, with no feature changes mixed in. Without a pre-agreed route, the same fix
would likely have waited until Monday, or been bundled with "while we're at it"
changes that make a failure much harder to diagnose.

## Common mistakes

- **Freezing too late.** If upgrades are still being rushed through in the
 last days before the freeze, the freeze protects nothing. The risky work has
 to finish early enough for normal traffic to test it.
- **Freezing security along with features.** A blanket "no changes" rule
 pushes people to either ignore a real advisory or bypass the process
 entirely.
- **Forgetting things that change themselves.** Auto-updates, SaaS apps, tag
 managers and provider-side settings can alter the checkout without a deploy.
- **Bundling.** An emergency fix plus "a small tweak" means two possible causes
 if orders drop.
- **Testing only that the page loads.** A checkout page can load and still fail
 to take payment or send the confirmation email. Test the full order path.
- **No baseline.** Without knowing normal order volume for a Friday evening,
 you cannot tell a quiet hour from a broken checkout.

Honest limitations: a freeze reduces the number of changes, not the number of
failures. Payment provider outages, carrier problems, traffic spikes and
third-party script failures can all happen with zero deploys. The freeze is one
control alongside load preparation, monitoring and a clear incident plan, not a
guarantee.

## FAQ

### When should a Black Friday code freeze start?

There is no single rule. A common approach is to finish platform and plugin
upgrades in October and start the freeze one to two weeks before Black Friday,
which in 2026 means early-to-mid November. Larger or more complex stores
usually freeze earlier.

### Should I turn off WordPress auto-updates before Black Friday?

For revenue-critical stores, replacing unattended auto-updates with a daily
reviewed check during the freeze is reasonable, provided someone actually
reviews updates and applies security fixes through the exception route.
Turning auto-updates off and then ignoring updates is worse than leaving them on.

### What if a security fix is released on Black Friday itself?

Read the advisory and decide whether the store is exposed. If it is, apply the
fix (or a temporary mitigation) through the exception route with the full test
plan, at the lowest-traffic hour you can reasonably wait for. If it is not
exposed, schedule it for the day after the freeze ends.

## Monitoring the freeze

The test plan above has two parts that are tedious to do by hand all week: is
the store still taking orders at a normal rate, and did anything change right
before a problem started. If you maintain WooCommerce stores, Pingvera can
receive order events through its WordPress connector, compare order flow to an
hourly baseline and alert when the site is up but orders have stopped; deploys
and incidents appear on the same timeline as those order events, so an
emergency patch and any drop that follows it sit side by side. It also watches
for accidental noindex and unexpected redirects after releases. For the
background, see
[catching a WooCommerce store that stopped selling](https://pingvera.com/blog/woocommerce-orders-stopped-anomaly-detection.html)
and [the unified timeline](https://pingvera.com/blog/unified-timeline-client-site-monitoring.html).

For the wider peak plan (demand modelling, load rehearsal, staffing), read the
[ecommerce peak sales readiness checklist](https://pingvera.com/blog/ecommerce-peak-sales-readiness.html);
for the checks after any release, use the
[post-deployment website checklist](https://pingvera.com/blog/post-deployment-website-checklist.html);
and for feeds, see [product feed monitoring](https://pingvera.com/blog/product-feed-monitoring.html).

## Sources

- [WooCommerce 11.2.0: Release notes (WooCommerce Developer Blog, 7 October 2026)](https://developer.woocommerce.com/2026/10/07/woocommerce-11-2-0-release-notes/)
- [WooCommerce developer changelog](https://developer.woocommerce.com/changelog/)
- [CVE-2026-92400: Payment Gateway for PayPal on WooCommerce before 9.2.1](https://www.thehackerwire.com/vulnerability/CVE-2026-92400/)
- [Google for Developers: Content API for Shopping deprecation and sunset](https://developers.google.com/shopping-content/guides/sunset)
- [WordPress Documentation: Plugin and themes auto-updates](https://wordpress.org/documentation/article/plugins-themes-auto-updates/)

Last reviewed: 10 October 2026