Bot Shield: IP Block & Rate Limiter

• Fixed: In the bot-protection log the "Rule" column was squeezed down to a single character on narrow screens. The log columns now have fixed widths, and "Rule" sits directly after "IP address" — so time, IP and rule are fully readable without scrolling sideways. The verbose "Decision" column now follows them: it is never truncated, but on narrow screens its end only becomes visible after scrolling sideways.

• Improved: The dashboard's proposal list now shows only network ranges that can actually be approved right now. Proposals
  whose network range cannot currently be resolved — usually because the network has sent no requests for more than 24
  hours — are hidden instead of reporting "could not be resolved" on approval. This also lowers the number of pending
  proposals in the coe:bot-shield:config:doctor diagnostic noticeably; right after a cache clear or plugin update it can
  read close to zero for up to a minute, until the networks' next requests have been collected. Nothing is lost: the
  proposals stay stored, the LLM analyst still sees its full history, and the proposal reappears as soon as the network
  sends requests again.

• Added: bin/console coe:bot-shield:config:prune lists stored CoeBotShield settings the plugin no longer knows and deletes
  them with --apply. These are leftovers of settings that earlier versions removed and that nothing reads any more.
  Without --apply the command only lists them and deletes nothing. It also covers values stored for a single sales
  channel, and it never prints a stored value. An entry whose deletion would also delete a valid setting, or that Shopware
  cannot delete, is listed with the reason and never deleted.
  Heads-up: deleting cannot be undone. Back up the system_config table before --apply.

• Changed: The plugin now checks which Bot Shield features your plan includes through the manufacturer's licence
  server. The plan overview in the plugin configuration shows the plans with their features, your active plan and the
  button to buy or switch.
  Heads-up: for the plan check the plugin sends the licence domain, the plugin and Shopware versions and the time of
  the request to the manufacturer's licence server, never data of your customers or visitors. To keep your plan up to
  date, your shop's scheduled task runner must be running.

• Changed: Approving or rejecting block proposals and the LLM analyst's connection test are now available through the
  Admin API only on a plan that includes the respective feature. Without it, the connection test reports that the LLM
  analyst is not included in your plan.

• Changed: Settings cards for features your plan does not include now read as locked — the card content is greyed out and cannot be operated, and a note at the top of the card names the plan that includes it. Every settings card shows its plan tier (Free/Basic/Pro). Stored values stay unchanged. On the dashboard, the notice for a feature your plan does not include renders as a regular card with a heading — the same way the locked settings cards look, with a preview and an upgrade button; the Edge Export page carries the same notice. The notice texts do not name a fixed plan but follow your licence instead.

• Changed: The security-check and overload-refusal texts now follow the language of the sales channel the visitor is on, instead of the language set in their browser. An English sales channel therefore answers German-speaking visitors in English too.

• Added: The bot-protection log now also shows when the AI analyst actually blocked a network — until now only the cases where a safeguard prevented the block were visible. The entry names the confidence of the judgement and whether protection was enforcing or only observing at the time of the block.

• Improved: The audit log names the AI analyst's decisions and skipped fleet blocks in plain language instead of an internal key or technical token. "LLM analyst: block skipped (safeguard)" and "LLM analyst: block held (no signature)" read as text; "LLM analyst: proposal created" stands for a finding put to you for approval; "LLM analyst: limited to busiest networks" says that a run judged only the most conspicuous networks — and with it, why not every network appears in a run. Skipped fleet blocks carry a readable label instead of an internal key.

• Added: Protection against mass account and order creation (from Basic). Bot Shield recognises an unusual number of registrations in a short time, plus suspicious email-domain patterns; guest registrations count towards it. When the shop is over its registration limit, only an address that is itself sending an unusual number of registrations gets a response — anyone submitting a single registration is left alone; how many registrations per address and minute are allowed is set in the settings (default: 3). The response is "HTTP 429 – please try again later" instead of a hard block, or alternatively the existing proof-of-work challenge: real customers solve it and pass, while automated bulk sign-ups fail; headless/store-API calls are throttled. The error page for refused registrations and orders (HTTP 429) names contacting the shop directly besides trying again. In "Observe" mode it only records. Addresses on the allow list are exempt from every check at registration. Every decision appears in the same audit log as the other gate decisions, and nothing is ever automatically cancelled or rejected.

• Added: Registration waves from a single network range are now detected across hours, not just per minute. When one network range creates more accounts within the configured time window than the configured limit, the next registration from that network receives a proof-of-work task; real visitors solve it once and are not asked again. Time window, limit and response are configurable.

• Added: Addresses that accumulate an unusual number of accounts now receive a proof-of-work task at registration — targeted, not shop-wide. When Bot Shield counts at least as many distinct accounts at one normalised address within the detection window as configured, the next registration from that address is served the existing proof-of-work task; real visitors solve it once, and every other visitor to the shop is unaffected. Orders at an address widen the room it gets: Bot Shield checks the shop's actual orders at that address, including orders placed before the plugin was installed and orders by guest customers; cancelled and unpaid orders do not count as valid, and what counts is the order's current state, not an open editing draft. A single paid or completed order does not lift the protection at that address for good: each such order allows as many further accounts at that address within the detection window as the "Cluster enforcement threshold" sets; beyond that, registrations from the address receive the configured address cluster reaction again — new registrations and guest checkouts at that address, a genuine resident's included; logged-in customers are never affected. Addresses with fewer accounts than the threshold are never affected. Cancelled orders are set against the valid orders: each cancelled order takes away the extra accounts one valid order allows there; where an address has at least as many cancelled orders as valid ones, the plain "Cluster enforcement threshold" applies to it again. An address whose orders are mostly cancelled therefore gains no extra room from the few that went through. In Observe mode the detection is only recorded. Threshold, response and detection window are configurable; matches appear in the audit log under the rule "address_cluster", each with a short address reference that cannot be traced back to the address, so you can see how many different addresses are affected — the address itself is not stored. Requires the Basic plan.

• Added: Address clusters and network ranges over the registration limit can now be refused outright instead of being challenged with a proof-of-work task. The settings "Address cluster reflex" and "Reaction for a network range over the limit" gain the option "Answer with HTTP 429": the next registration from such an address or network range receives the "Too many requests" notice — even when a proof-of-work task was already solved, because a solved task proves a browser, not a genuine address. For network ranges this also covers registrations through the Store API. The audit log lists these refusals as "Throttled" under the rules "address_cluster" and "register_volume_subject". Only acts in Enforce mode; requires the Basic plan.

• Added: Protection against mass registrations on brand-new email domains. When an unusual number of accounts is created in a short time on a domain that only recently appeared in the shop, the store can serve the proof-of-work challenge at sign-up. Detection evaluates the shop's actual accounts — it works immediately, with no warm-up period, and established domains such as large freemail providers do not trigger the check. No domain is ever permanently banned: a genuine company domain is served normally after one solve and counts as known shortly after.

• Added: Registration and checkout now recognise automated non-browser clients. When a client identifies itself as an app runtime (e.g. Electron) rather than a real browser, the proof-of-work challenge can be served at sign-up and order placement; headless/store-API calls are throttled (HTTP 429). Alternatively the hit is only flagged. The marker of desktop apps such as Discord or other Electron applications in the User-Agent never counts on its own as evidence against a whole network: a network range from which many visitors use such an app is not blocked as a bot fleet for that reason alone — neither by the automatic fleet detection nor by the LLM analyst; for the individual address the marker counts together with a second indicator.

• Added: The security check at registration and checkout is presented only where it can actually be answered. A form submitted in the background is not given an unanswerable check; it is logged and passed on, and where an address exceeds the per-minute register limit the shop still answers with a limit. When the check interrupts a registration, the entries are back in the form afterwards; the password is deliberately not kept and has to be entered again. A passed check covers exactly one successful registration or order — consistently across every protection (account velocity, new email domains, non-browser clients) and for registered and guest flows. An abandoned or failed attempt (e.g. a mistyped email) does not spend it, and ordinary browsing stays cleared for the configured duration.

• Added: Address-deduplication fraud flag (from Basic). When a configurable number of distinct customers share the same shipping address, all affected accounts receive a configurable tag automatically; the tag is removed once the observation window expires with no new hit. Detection fires on both registration and order placement and also covers guest registrations. Only hashed addresses are stored — never plain-text data.

• Added: After the update, the shop automatically protects expensive page views from unknown visitors with a short security check, before any block is involved. It applies to all regular page views in the shop — the home page, category and product pages as well as login, registration, the cart view and the checkout steps; images, scripts and other files are excluded. If the protection mode is set to "Enforce", unknown visitors see a short security check on their first page view, which normally completes on its own in under a second and then opens the page they asked for — with their filters, session and cart intact. It normally appears once per session: a passed check is honoured for the rest of its validity (30 minutes by default) on all further pages. And it always lands on the page view, never on submitting a form the visitor has already filled in. In "Observe" mode the check is only logged and the page is served as usual. Signed-in staff, confirmed search engines and visitors who have already passed the check are skipped. The feature is on by default and can be switched off again at any time. The check always costs the same small amount (about 191 tries). bin/console coe:bot-shield:config:doctor reports whether the check is in effect. Please note: the check requires JavaScript. Search engines that can be confirmed by a reverse DNS entry (Google, Bing, Apple, DuckDuckGo, Yandex) are skipped automatically. The link-preview services of Facebook, X and LinkedIn cannot be confirmed that way — they publish IP ranges only. In "Enforce" mode those platforms therefore stop showing previews for shop pages until you add the relevant addresses to the allow list. The same applies to your own monitoring services.

• Improved: A passed security check is now bound to the browser session in addition to the IP address. A passed check can therefore no longer be transferred to another device or browser — not even when both use the same IP address. Conversely, if the IP address changes during a visit (common on mobile networks), the short check is shown once more.

• Added: Protection against bots that fire background requests without cookies (all plans). Four background requests the shop never serves from the cache — the live purchase-limit lookup of clearance-sale products, the cart widget, the cart side panel and the search suggestions — never receive the security check (proof-of-work task), even with the automatic check switched on. Instead, every browser receives a security cookie with its first such request. Requests carrying the cookie are counted per browser session and request type, against the configured background-request value but at least 30 per minute, so a cookie copied to many machines shares one budget. A client that discards the cookie receives a new one with its next request without cookie, and that request counts against the network limit. Requests without that cookie are counted per network (IPv4 /24, IPv6 /48) and request type; above the configured value (default: 60 per minute) the shop answers with "HTTP 429 – too many requests" in "Enforce" mode and records the request in the audit log as "Throttled", while in "Observe" mode the overrun is only recorded in the audit log as "Flagged" (audit log from Basic). Real customers in the same network are not affected. The value 0 switches the protection off.

• Fixed: The cookie settings now show the names and descriptions of the Bot Shield cookies.

• Added: Fleet detection now also recognises coordinated access that trips no individual rule — many addresses in one network range requesting pages at a steady pace, in near-identical volume and almost exclusively page content, without cache-busters, odd parameters or unusual browser identifiers. A match appears as a proposal in the dashboard; nothing is blocked without your approval. A proposal is a lead, not a verdict: look at the range before you approve it — approving blocks the whole range — and rejecting one has no further effect. Network ranges that the admin was recently worked from are exempted automatically and logged on their own line.

  The proposal names the affected network range in plain text — and marks it when it is your own network, so you do not have to look up which address you work from. After an approval you are told what was actually blocked and what was not: a network range on your allow list is never blocked by an approval. The automatic exemption for ranges the admin was worked from lasts 30 days after the last login. You can review and approve proposals on every plan that runs the detection.

  Heads-up: Detection is active right after the update. You can switch it off in the plugin settings.

• Improved: Bot Shield now detects automated clients that call the shop's widget and background routes like
  a normal page load instead of as the browser's background request, and factors this in together with
  other signals when blocking on the paid plans — it never blocks on this signal alone, so genuine customer
  traffic from the same networks is more reliably spared.

• Added: Bot Shield detects clients that fetch only the live purchase-limit lookup without ever having loaded a page of the shop — a pattern a real browser cannot produce, because that lookup is triggered from a loaded product page in the first place. Such clients appear in the audit log as "Flagged" from Basic; optionally they are answered with HTTP 429 instead, for that one lookup only. A client that loaded a shop page is never flagged, no matter how many requests it makes. This also holds for requests carrying the security cookie: they are checked like any other request. A shop page counts if the address loaded one within the configured window.

• Improved: Detection now also logs suspicious traffic below the block threshold (rate-limit overages, counted strikes, fleet evaluations with no match) and keeps a multi-minute per-network history — making slow, distributed access traceable where a single snapshot cannot.

• Added: A new overview openly documents which traffic the protection does not see by itself — files the web server delivers directly, pages answered from the HTTP cache, access below the configured limit, distributed, inconspicuous access patterns, and requests that reach the shop through its API rather than as rendered pages. For each point it states why that is so and what you can do instead. The protection-mode help text now points at this overview.

• Changed: The default duration of an automatic block is raised from 60 to 360 minutes. A block shorter than the attack expires in the middle of it and the traffic returns; the documented case ran about four hours. The field's help text now explains both directions: too short lets the attack come back, too long keeps a wrongly flagged address blocked for that duration — you can lift an individual block at any time in the block list, or add the address to the allow list.

  Heads-up: An existing installation keeps the value it has today — the new default applies to new installations. Check "Auto-block duration (minutes)" in the plugin settings and raise it if it still reads 60.

• Changed: Four networks that produced real orders in the shop no longer count as datacenter networks (82.38.220.0/24, 95.134.61.0/24, 178.95.140.0/22, 178.92.199.0/24). An automatic block from these networks now offers the security check instead of a hard refusal, and they are no longer blocked as a whole network.

• Changed: A logged-in customer is now exempted from a block only when the account is trustworthy — old enough and with a completed order older than a configurable window (new setting "Minimum qualifying-order age (hours)", default 24 h). A throwaway account created by automated registration can therefore no longer instantly re-earn the exemption. Aged bot accounts with only a freshly placed burst of orders are therefore no longer wrongly reprieved. The thresholds are configurable and the differentiation can be switched off entirely. If the trust check errors or is switched off, the reprieve is now withheld as a safe default. The check applies only to traffic that already hit a block — genuine new customers with no block history are never affected.

• Fixed: Signed-in, trusted customers were blocked even when their IP address was on the block list — the
  customer reprieve now reliably recognises them and lets them through.

• Improved: The AI analysis now judges suspicious networks with memory — it sees its own earlier assessments of the same network and the recent request history, so it more reliably spots steady low-rate persistent access that looks unremarkable in a single snapshot.

• Fixed: Block proposals from fleet/AI detection were lost on a cache clear (e.g. on every update) and then no longer appeared in the dashboard. Proposals are now stored durably with their reason and category and stay visible for approval.

• Fixed: Approving an older AI analyst proposal reported "approved and blocked" although no block was created. Proposals are now valid for 24 hours (previously 7 days) and then disappear from the overview; if a proposal can no longer be applied, an error message is shown and the list is refreshed.

• Fixed: The LLM analyst's open-proposals list is now laid out in clean columns — the text no longer overlaps the action buttons.

• Changed: The AI analyst no longer sends IP or network addresses to the configured AI provider, only pseudonymised handles with their behavioural data. Addresses are resolved inside the shop only; proposed and automatic blocks work as before.

• Fixed: Under sustained high traffic, newly suspicious networks could after a while no longer be blocked automatically or proposed. Internal mappings now expire individually and make room for new ones; IPv4 and IPv6 networks use separate quotas.

• Fixed: The DNS check for search-engine crawlers (Googlebot, Bingbot, Applebot, DuckDuckBot, Yandex) could hold a request for an unlimited time. Where the plugin can read the server's DNS configuration, each lookup is now cancelled after about one second. Otherwise it checks via the system resolver as before and writes a notice to the shop log.

• Fixed: If a visit by one of these crawlers could not be checked by DNS in time (lookup limit reached or DNS timeout), it was blocked or sent to the check page like an unconfirmed crawler, and visitors received a blank page with no explanation. It now receives a temporary "503 – please try again later" response instead and is checked on its next visit; this includes the automatic security check for unknown visitors. That response now states what happened and asks for a retry in about a minute — and for a blocked address where the security check is available it is offered right away, so a wrongly classified person gets through immediately. Addresses you blocked by hand receive the normal block response instead of this page — a block you set yourself stays absolute, and no way around it is offered.

• Fixed: Googlebot and Bingbot visiting over IPv6 were not recognised as verified crawlers and could therefore be blocked or sent to the check page. Verification now covers both IPv4 and IPv6 addresses, and DNS lookups for not-yet-known crawler addresses are rate-limited.

• Fixed: On shops installed in a subdirectory or using a language path in the domain (e.g. /de), the blocked page redirected blocked visitors to the wrong address. The redirect now leads to the blocked page of the correct sales channel, including for responses served from the HTTP cache.

• Fixed: For domains with non-ASCII characters (internationalised domain names), the blocked page redirected blocked visitors from the HTTP cache to an address without the language path, and the blocked page itself could be redirected again. The redirect now leads to the blocked page of the correct sales channel there as well; a failure to load the domains is written to the shop log.

• Fixed: If the selected Shopping Experience for the blocked page cannot be rendered, the error is now written to the shop log (the visitor still receives a plain 403 response).

• Improved: The check page logo is now loaded in the scope of the visitor's sales channel instead of with system privileges; private media stay excluded as before.

• Improved: A blocked client with a rotating session cookie no longer triggers a database query on every request.

• Fixed: During maintenance mode the maintenance page is now shown reliably. Previously the bot protection could show its challenge page to suspicious visitors instead — and because both answer with "503", the shop could look broken while it was not.

• Improved: The edge-export directories (backups and the .htaccess target folder) are no longer created writable for all users; a backup directory that older versions created writable for all users is restricted to owner and group the next time the .htaccess is written.

• Changed: If the storage directory for edge-export backups is a symbolic link or owned by another user, the .htaccess is not written and a notice is logged.

• Changed: Automatic blocks for crawler visits whose DNS check is still pending are no longer written to the edge export; they apply in the shop only, where the crawler is checked again.

• Improved: The /16 CIDR aggregation threshold's help text now states that 0 switches it off and that the value 1 produces the broadest possible block; coe:bot-shield:config:doctor also warns when 1 is configured.

• Added: The dashboard now has its own card showing which rules applied in the last 24 hours — blocked/checked and, new, waved through (for example via the allow list or an existing check), each with its hit count.

• Fixed: An empty dashboard card could mean "nothing happened" or "nothing is being recorded here", and both looked the same. The card now says when no decisions are being recorded on the current plan or with detection switched off.

• Fixed: "Strike counted" entries caused by a suspicious request signature now name that signature as their rule in the audit log instead of always "rate_limit".

• Improved: The block list now visibly marks expired entries as expired instead of showing them like active ones.

• Fixed: Timestamps in the admin lists (block list, allow list, audit log, Edge Export) are now shown in the timezone configured in your profile.

• Added: Protection level for scraper protection (Free). One choice (Light, Standard, Strict, Custom) sets the request limits for listing and product pages, the strikes before an automatic block, the signature score, the automatic block duration and the limit for background requests without cookie at once. Standard equals the previous default values. Your own values in these six settings are kept at every level and apply under "Custom". On an existing shop "Custom" is selected after the update, so nothing changes until you choose another level; a new installation starts on "Standard".

• Added: Protection level for registration protection (Basic). One choice (Light, Standard, Strict, Custom) sets the registration limits per minute for the shop and per client, the account limit per network range, the account threshold per street address and the reactions of the five registration checks at once. Standard equals the previous default values; Strict refuses bursts, network ranges over their limit and address clusters with HTTP 429. Your own values in these nine settings are kept at every level and apply under "Custom". On an existing shop "Custom" is selected after the update, so nothing changes until you choose another level; a new installation starts on "Standard". The console self-diagnostic also shows, for this level, the value in effect.

• Added: Protection level for fleet detection (Basic). One choice (Light, Standard, Strict, Custom) sets the automatic range block for fleets and the review proposals for clean fleets at once. Standard equals the previous default values (both on); Light switches the automatic range block for signature and User-Agent fleets off — those ranges are then neither blocked nor reported, only clean-fleet detection keeps producing proposals for your review; Strict equals Standard. Your own settings of the two switches are kept at every level and apply under "Custom". On an existing shop "Custom" is selected after the update, so nothing changes until you choose another level; a new installation starts on "Standard". The LLM analyst (Pro) is not covered by this level: it keeps blocking ranges at or above its "Auto-apply confidence threshold" and proposing those below it.

• Added: The protection levels show what they do. A table under the level dropdown lists every setting the level governs together with its values for Light, Standard and Strict — marking where a level uses the same value as the one before it, and where a value is the same at every level. It is visible whether switching a level changes anything at all. While a protection level is selected, the settings it governs cannot be edited; the value that applies is shown in the table. Pick "Custom" to set the settings yourself again; your own stored values stay untouched and apply again as soon as you switch back to "Custom".

• Changed: The plugin settings are regrouped; all settings keep their values.

• Added: Configuration self-diagnostic via the console (bin/console coe:bot-shield:config:doctor) — reports operating mode, licence tier and signal diagnostics with a PASS/WARN/FAIL verdict and names settings that are enabled but ineffective. The overall result in the last line is labelled (Verdict: …). It takes the active plan into account: cost gate, CIDR aggregation, proposal delivery and purchase-limit coherence report that the feature does not run in the active plan when the plan does not include it, and do not drag the overall verdict down to "WARN". It also shows the selected protection level and, for each of the six values, the value in effect and where it comes from (level or your own setting); reports when proposals are pending but no flow reacts to the "botshield.finding.pending" event; reports settings whose stored value does not match the field type – for example "0" as text in a yes/no switch or "360" as text in a number field, as bin/console system:config:set stores them without --json – naming the setting, the stored and the expected type, never the value itself; shows in one line how many no-longer-known settings (see coe:bot-shield:config:prune) are stored and names the command that cleans them up, without affecting the overall result; shows how many LLM analyst findings above the confidence threshold were held back by the safeguards — split into "not a data-centre network" and "no signature tripped", each as the number of networks and hits within the audit log retention period and within the last 24 hours; and counts the AI analyst's blocks — split into enforcing and observing, over the log's retention period and over the last 24 hours. Together with the line about findings held back by safeguards, it is readable without database access whether the AI analyst gets to block at all.

• Heads-up: If an upstream server or CDN serves the page cache, the shop never sees those page views and the detection stays inert. bin/console coe:bot-shield:config:doctor reports which case applies to your shop.

• Removed: The NAT exoneration for shared carrier connections and its settings "NAT exoneration" and "NAT session cardinality threshold". It never took effect, because it relied on a session cookie the storefront does not set. This retracts the 7.0.0 note that customers behind shared carrier connections "are now recognised by their genuine browser and session behaviour and are no longer auto-blocked". For known shared addresses the allow list remains the instrument; logged-in regular customers stay covered by the customer reprieve.

• Removed: The settings "Other (asset) rate limit" and "Rate limit window (seconds)". The window is fixed at 60 seconds and the limit for other requests at 300 requests per window — the previous defaults. A value you set yourself is no longer used.

• Removed: The four User-Agent rotation and monoculture fleet settings. Detection works unchanged with the previous defaults (5 User-Agents per address, 3 rotating addresses, at most 2 User-Agents, 10 addresses). A value you set yourself is no longer used; the defaults apply.

• Removed (Pro): The LLM classification of auto-blocked networks as datacenter networks and its switch in the LLM analyst settings. In practice it classified no network; networks are now recognised as datacenter networks from the bundled list alone, and every other network keeps receiving the security check instead of a hard refusal on an automatic block. No network prefixes are sent to the LLM provider any more. This retracts the 7.0.1 note.

• Fixed: The DNS check for Googlebot and Bingbot could hold a request for an unlimited time. Where the plugin can read the server's DNS configuration, each lookup is now cancelled after about one second. Otherwise it checks via the system resolver as before and writes a notice to the shop log.

• Fixed: If a Googlebot or Bingbot visit could not be checked by DNS in time (lookup limit reached or DNS timeout), it was blocked or sent to the check page like an unconfirmed crawler. It now receives a temporary "503 – please try again later" response instead and is checked on its next visit.

• Fixed: For domains with non-ASCII characters (internationalised domain names), the blocked page redirected blocked visitors from the HTTP cache to an address without the language path, and the blocked page itself could be redirected again. The redirect now leads to the blocked page of the correct sales channel there as well; a failure to load the domains is written to the shop log.

• Fixed: An edge-export backup directory that older versions created writable for all users is restricted to owner and group the next time the .htaccess is written.

• Changed: Automatic blocks for Googlebot/Bingbot visits whose DNS check is still pending are no longer written to the edge export; they apply in the shop only, where the crawler is checked again.

• Changed: If the storage directory for edge-export backups is a symbolic link or owned by another user, the .htaccess is not written and a notice is logged.

• Fixed: On shops installed in a subdirectory or using a language path in the domain (e.g. /de), the blocked page redirected blocked visitors to the wrong address. The redirect now leads to the blocked page of the correct sales channel, including for responses served from the HTTP cache.

• Fixed: Googlebot and Bingbot visiting over IPv6 were not recognised as verified crawlers and could therefore be blocked or sent to the check page. Verification now covers both IPv4 and IPv6 addresses, and DNS lookups for not-yet-known crawler addresses are rate-limited.

• Improved: A blocked client with a rotating session cookie no longer triggers a database query on every request.

• Fixed: If the selected Shopping Experience for the blocked page cannot be rendered, the error is now written to the shop log (the visitor still receives a plain 403 response).

• Changed: The AI analyst no longer sends IP or network addresses to the configured AI provider, only pseudonymised handles with their behavioural data. Addresses are resolved inside the shop only; proposed and automatic blocks work as before.

• Improved: The check page logo is now loaded in the scope of the visitor's sales channel instead of with system privileges; private media stay excluded as before.

• Improved: The edge-export directories (backups and the .htaccess target folder) are no longer created writable for all users.

• Fixed: Approving an older AI analyst proposal reported "approved and blocked" although no block was created. Proposals are now valid for 24 hours and then disappear from the overview; if a proposal can no longer be applied, an error message is shown and the list is refreshed.

• Fixed: Under sustained high traffic, newly suspicious networks could after a while no longer be blocked automatically or proposed. Internal mappings now expire individually and make room for new ones.

• Fixed: The "Full setup guide" link on the Edge Export page pointed at an unreachable address and led nowhere; it now points to the official setup guide.

• Fixed: The AI analyst and fleet detection could automatically block whole consumer and mobile networks (e.g. Telekom, Vodafone or o2 ranges) as a /24 and lock out real customers. Automatic blocks now apply only to networks identified as datacenter/hosting; consumer and unknown networks are no longer blocked at subnet scale.

• Fixed: An automatic block suggestion without a single detected attack-signature hit is no longer hard-blocked; it is discarded and recorded in the audit log (no manual review queue).

• Fixed: A range already on the allow list is no longer created as a block entry in the first place.

• Improved: The edge export (--apply) now reports "Written" vs. "Unchanged" honestly and refreshes the current block list before exporting, even after changes made outside the admin UI.

• Note (data protection): To judge more accurately, the AI analyst now sends the actual IP/network address of a suspicious visitor together with its behavioural profile to the configured AI provider. Please ensure a data-processing agreement (DPA) with that provider is in place where required.

• Added: The LLM analyst (Pro) now sends only a limited number of network aggregates per run to your LLM provider (default 50, adjustable), bounding the payload per call.

• Changed: The LLM analyst now runs hourly by default instead of every 5 minutes — this significantly lowers the default token spend against your provider. Existing installs that never changed the interval adopt the new default automatically on the next plugin update; a custom interval you set is preserved. For faster reaction you can lower the interval any time via Shopware's standard scheduled-task surface.

• Improved: The block list and allow list now have a right-sidebar search — like the audit log — to filter entries by IP address or CIDR.

• Improved: The block list, allow list and audit log now page through long lists with a fixed bottom pagination bar.

• Fixed: On the dashboard the proposals card was misaligned in width beneath the KPIs, and with no open proposals a distorted icon showed instead of the "Keine offenen Vorschläge" message.

• Added: Edge export now collapses auto-blocked IPs from datacenter and hosting networks into a /24 CIDR rule sooner than requests from consumer networks — tighter block lists for purely machine ranges, while consumer networks keep the cautious threshold. New threshold configurable in the Edge Export settings (Pro plan; set to 1 to disable).

• New (Pro): For shops with a connected LLM, a new scheduled run classifies recently auto-blocked subnets via
  the LLM as datacenter/hosting networks, refining the hard refusal (HTTP 403) over the proof-of-work
  challenge. Off by default; enable it in the LLM analyst settings. Only the /24 network prefixes of
  blocked subnets are sent to the configured LLM provider — never an individual visitor address.

• Added: Auto-detected bots from datacenter and hosting networks are now refused outright (HTTP 403), while requests from consumer networks keep the proof-of-work challenge — sparing resources on purely machine traffic. On by default (Basic plan); can be turned off in the Detection settings.

• Fixed: Blocked IP addresses were still served cached pages while the HTTP cache was active — the block now also applies on a cache hit.

• New (Basic+): Blocks that take effect on a cache hit now also appear in the audit log and situation dashboard.

• Fixed: The AI analyst and fleet detection only became active after clearing the cache once they were enabled in the admin. The setting now takes effect on the next scheduled run.

• Fixed: Changed retention settings (audit entries and edge-export backups) now also take effect on the next scheduled run instead of only after clearing the cache.

• Fixed: Edge Export now truly writes automatically — with the "Allow the Apache auto-write" switch on (Pro plan), a background task keeps the managed .htaccess block in sync periodically: newly blocked IPs reach the .htaccess and expired blocks leave it again, without clicking "Apply".

• Added: Edge Export can now aggregate blocked single IPs into network ranges (/24, optionally /16) once a configurable number of IPs in a network are blocked — keeping the .htaccess small and fast. Conservative by default; hand-maintained entries and the allow list are never touched.

• Added: a coe:bot-shield:edge-export console command (--dry-run/--apply/--remove) for deployment, cron and the emergency case when the admin UI is unreachable.

• Added: the Edge Export page now shows the entry count, generation time and block size — with a hint to enable aggregation when the block grows large.

Heads-up: after installing/updating, restart the message consumer so the new edge-export sync task is registered.

• Added: a "Test connection" button for the LLM analyst — checks from the configuration whether URL, key and model are reachable, and shows the response time.
• Changed: the audit log now writes robustly — a single malformed record no longer blocks the whole write.
• Added: a coe:bot-shield:audit:doctor command that checks the audit chain (buffer → task → database) and pinpoints where it breaks, should the log still stay empty on an installation.
• Changed: the default LLM request timeout is raised from 10 to 120 seconds — reasoning models were regularly hitting the limit. The value must stay below the message-consumer time limit (noted in the field).
• Fixed: an empty LLM response (empty content from reasoning models) is now treated as "unavailable" instead of an empty analysis.

Heads-up: after installing/updating, restart the message consumer and reload the PHP workers (FPM/OPcache) so every worker runs the new build.

First release in store