# The GitLab AI Gateway Patch Needs a Host Receipt

> GitLab fixed a critical escape from a prompt-template sandbox in its self-hosted AI Gateway. The repair should end with proof of the running image, a review of who could create custom flows, and a decision about exposed credentials.

- **Author:** Kubilay Tunca
- **Published:** 2026-10-03
- **Category:** For Developers
- **Tags:** AI Agents, GitLab, Application Security, Incident Response
- **Canonical URL:** https://cyber-security-in-plain-english.com/post/developers/news/gitlab-ai-gateway-patch-needs-host-receipt

---

A developer writes a custom AI workflow. The workflow contains a prompt template, the ordinary scaffolding that tells a model what role to take and how to arrange its answer. On an affected self-hosted GitLab AI Gateway, a specially shaped flow configuration could cross the template's intended boundary and reach the operating system beneath it.

That is the concrete problem behind CVE-2026-90970. GitLab published the record on 2 October 2026 and described a path from authenticated Duo Agent Platform access to arbitrary command execution on the gateway. The company scored it 9.9 out of 10 and issued fixed AI Gateway versions 19.2.4, 19.3.2, and 19.4.1. [The GitLab-authored CVE record names the affected ranges and the three repaired releases](https://cveawg.mitre.org/api/cve/CVE-2026-90970).

The reassuring part matters too. As of 3 October 2026, this was not a report of an internet-wide outbreak. CISA's assessment in the CVE record marked exploitation as “none,” and GitLab's public material did not include a working exploit. GitLab-operated gateways had already received the fix. The teams with an immediate job were those running their own AI Gateway, not every organisation that happened to use GitLab Duo. [Independent coverage from The Hacker News made the same hosted-versus-self-hosted distinction](https://thehackernews.com/2026/10/gitlab-patches-critical-self-hosted-ai.html).

Updating is the first move. It should not be the last one. A replacement container image is a promise until the running workload, its authority, and its earlier exposure have been checked. The useful lesson from this flaw is larger than one product: a prompt sandbox can fail into a machine that holds real credentials and real network access. The repair therefore needs a host receipt, not a dashboard that merely says “upgrade complete.”

## What GitLab actually disclosed

The product names make this incident sound more mysterious than it is. The AI Gateway is a service between GitLab's AI features and the model providers that answer them. GitLab describes it as a standalone service that receives AI requests and connects them to the relevant models. Organisations can use GitLab's managed gateway or operate one inside their own environment. [GitLab's current gateway documentation sets out those two arrangements](https://docs.gitlab.com/administration/gitlab_duo/gateway/).

Self-hosting changes who owns the machine and the repair. It can keep request and response data inside an organisation's environment, avoid calls to an external model API in some configurations, and put the model-serving lifecycle under local control. [GitLab documents those reasons for a self-hosted setup](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/). It also means the organisation owns the container version, secrets, logs, network paths, and evidence when something goes wrong.

The vulnerable input was a specially crafted flow configuration. A custom flow is a team-defined workflow made from agents and steps, with triggers that decide when it runs. It can be started from GitLab's interface or an integrated development environment. [GitLab's flow documentation describes custom flows in those terms](https://docs.gitlab.com/user/duo_agent_platform/flows/). This matters because the unsafe material did not have to arrive as a suspicious packet from an anonymous internet address. It could arrive through a feature built for authenticated collaboration.

GitLab says an authenticated user needed Duo Agent Platform access. The published record does not narrow that to a more precise role, nor does it spell out every condition needed for the escape. What it does say is enough to define the security boundary: a user who was allowed to supply a flow configuration could, under certain conditions, escape the prompt-template sandbox and execute commands on the gateway. The weakness is classified as CWE-1336, improper neutralisation of special elements in a template engine. [Those details come directly from the CVE record](https://cveawg.mitre.org/api/cve/CVE-2026-90970).

There is one scope detail worth checking rather than assuming. GitLab's custom-flow documentation says a project must have the Duo Agent Platform enabled and the user must have at least the Developer role to run a custom flow; the project setting can also allow or deny custom and external flows. [The documented control sits under the project's AI-native features settings](https://docs.gitlab.com/user/duo_agent_platform/flows/custom/). The CVE record, however, says only “Duo Agent Platform access.” A response team should use the broader description until its own configuration proves a smaller set of people could reach the vulnerable path.

The affected version ranges are unusually important because the gateway has its own version. GitLab lists every AI Gateway release from 18.1.6 up to, but not including, 19.2.4 as affected, along with 19.3 releases before 19.3.2 and 19.4 releases before 19.4.1. There is no repaired 18.x or 19.1 release in the advisory. A team that checks only the GitLab application version can therefore produce a comforting answer about the wrong component.

That is the first operational conclusion. Ask which AI Gateway image is running. Do not ask whether “GitLab is patched” and accept one version number for a stack made of several moving services.

## How a prompt template reaches a shell

A prompt template is usually treated as text with slots. The program has a fixed instruction, inserts values such as a task description or repository context, and sends the result to a model. The mental picture is a document generator. That picture breaks when a template engine supports expressions, lookups, filters, or helper calls that carry more power than ordinary string replacement.

Template injection appears when untrusted material is interpreted as part of the template program rather than kept as a value inside it. Imagine a shipping label with boxes for a name and address. Safe handling writes the customer's text into those boxes. Unsafe handling lets the customer redraw the label's printing instructions. The visible input may still look like text, but the interpreter reads part of it as a command to the template system.

A sandbox tries to limit what those template instructions can reach. It may block dangerous objects, restrict available functions, or present a smaller execution environment. That is a useful layer. It is also software, with assumptions about every expression and object path the template engine can resolve. CVE-2026-90970 matters because the published outcome reached far beyond a strange model answer: arbitrary command execution on the AI Gateway.

The phrase “prompt-template sandbox” can lead teams towards the wrong threat model. This was not a claim that a language model became self-aware, ignored its system prompt, or invented a shell escape. The flaw was in software that prepared and processed a workflow around the model. [Security Affairs' account likewise places the weakness in custom-flow prompt-template handling](https://securityaffairs.com/200283/hacking/cve-2026-90970-critical-gitlab-ai-gateway-flaw-fixed.html). Ordinary application-security rules still apply even when the product feature has “AI” in its name.

The path is easier to reason about as four boxes. An authenticated person can submit or influence a flow configuration. The gateway parses a prompt template from that configuration. The sandbox decides which template operations are permitted. The gateway process runs on a host with files, environment variables, and network connections. The vulnerability crossed the third box and landed in the fourth.

That final landing point determines the possible damage. Command execution normally inherits the identity and environment of the vulnerable process. It does not automatically mean root on every nearby machine, access to every repository, or control of the whole GitLab instance. Those outcomes depend on container isolation, mounted files, environment variables, service permissions, reachable destinations, and local credentials. Treating “arbitrary command execution” as instant total compromise is sloppy. Treating it as a harmless prompt bug is worse.

The service's documented configuration shows why the host deserves attention. GitLab's installation instructions require signing and validation keys for JSON Web Tokens, and they show those values being passed to the gateway through its runtime environment. [The AI Gateway installation guide tells operators to generate and store those keys as sensitive values](https://docs.gitlab.com/install/install_ai_gateway/). Depending on the deployment, the process may also need routes to the GitLab instance and one or more model backends.

A gateway with command execution can therefore sit at a useful junction. The exact reachable data is installation-specific, so an article cannot honestly prescribe a universal rotation list. A response team can, however, identify the process identity, list its mounted files and environment-sourced secrets, map its outbound routes, and ask what an intruder running as that process could read or call. That turns a frightening score into a finite review.

## Why replacing the image is not proof

Container deployments encourage a dangerous shorthand: pull the fixed image, restart the service, close the ticket. That sequence can install the repair. It cannot, by itself, answer which image is now executing or what happened before the restart.

Tags are convenient names, not durable evidence. A deployment manifest might request `self-hosted-v19.4.1-ee`, while an old task continues to run because a rollout stalled. A node may have cached an earlier image. A Helm release can update successfully while one unhealthy replica remains. If the team records only the requested tag, it has recorded intent.

A host receipt records reality. For a Docker deployment, that means the running container ID, the immutable image digest behind it, the gateway's reported version if available, the container start time, and a successful health check. For Kubernetes, it means the rollout revision, image digest for every ready pod, restart counts, and the absence of old replicas. The exact command depends on the platform; the evidence does not.

This difference is easy to test. Suppose three gateway replicas serve traffic. The deployment object says 19.4.1, and two fresh pods use the repaired digest. The third pod has been stuck terminating since the rollout began and still receives traffic through a service endpoint. A ticket containing only the deployment's desired image says “fixed.” A receipt listing all three running digests says “one path remains.”

The version check must also respect GitLab's compatibility guidance. GitLab's self-hosted documentation tells operators to align the gateway image with their GitLab release, and its offline-deployment instructions describe an image tag based on the GitLab version. [The offline guide explains that matching scheme and the need to transfer updated images during an upgrade](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/offline_deployment/). Teams on an affected line with no listed repaired build should not improvise a mix of versions and call it supported. They should confirm a compatible upgrade route with GitLab, or disable the exposed feature while that route is settled.

A clean receipt also includes the source of the image. Pull from the registry and path named in GitLab's instructions. Record the digest you obtained at the time of the change. If an internal registry mirrors vendor images, preserve the mapping from the internal digest back to the reviewed upstream artifact. This is not ceremony. A version string can be typed into a manifest; a digest identifies the bytes that started.

Health belongs in the receipt because security updates can create pressure to ignore function. A gateway that fails after the update may trigger an emergency rollback to the vulnerable release. Check the normal request path, authentication between GitLab and the gateway, and the connection to the intended model backend. If rollback becomes necessary, the team should know that it is reopening a security exposure and should disable custom flows or isolate the service while it resolves the fault.

The fix deserves a short observation window. Watch new container starts, command failures, unexpected child processes, unusual outbound connections, and authentication errors. Keep that monitoring separate from the gateway process where possible. Logs stored only inside a disposable container can vanish during the very replacement intended to make the system safe.

A patch answers whether this input should still escape. A receipt answers whether the repaired code is really running everywhere. Keep both answers.

## The earlier window still needs a decision

As of 3 October 2026, CISA's assessment said it had no known exploitation, and the public reports did not describe attacks using this flaw. That lowers the reason for panic. It does not erase the period in which an affected gateway accepted flow configurations.

“No known exploitation” is a statement about available evidence, not a warranty for each installation. A self-hosted gateway may be available only to a small engineering group, or it may sit behind a broadly reachable corporate login. One team may have disabled custom flows. Another may have allowed hundreds of developers to create them. The same CVE score lands in very different local situations.

Start with reachability. Identify every project where Duo Agent Platform was enabled during the affected period. Check whether custom and external flows were allowed. Identify the users and automation identities that had the required access. Include accounts that have since been disabled, because the question concerns the earlier window. This is not an accusation against developers; it is a map of who could send input to the vulnerable parser.

Then preserve the flow history before pruning it. Save relevant configuration revisions, creation and modification events, initiating user identities, run times, and any available audit records. Search for configurations that were new, changed unexpectedly, or submitted by accounts whose own security is in doubt. Avoid turning the search into a public hunt for “malicious-looking prompts.” The exploit conditions were not fully published, and pattern matching against guessed syntax can create false confidence.

Host evidence comes next. Review process starts, child processes, container runtime events, file changes, and outbound connections for the gateway workload. Compare them with ordinary deployment and maintenance activity. A command spawned by the gateway process is more useful evidence than a prompt containing punctuation that someone finds suspicious. If runtime telemetry was not retained, record that gap plainly rather than replacing missing evidence with “nothing found.”

GitLab documents two different logging locations that can easily be confused. With data collection enabled, some code-generation and Duo Chat events appear in `llm.log` on the GitLab instance. GitLab also notes that detailed logs for self-hosted gateway and model activity remain in the organisation's infrastructure unless traces are configured for an outside observability service. [The logging documentation describes the `llm.log` behaviour](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/logging/), while [the broader Duo configuration guide explains the self-hosted tracing boundary](https://docs.gitlab.com/administration/gitlab_duo/configure/).

Neither statement promises a complete forensic record for this vulnerability. Chat events are not necessarily custom-flow parser events. Application traces are not a substitute for host process and network evidence. The useful approach is to collect what each layer can prove, state what it cannot prove, and avoid making one log carry the weight of the whole incident.

Credential review should be driven by exposure. List every secret available to the gateway process through environment variables, mounted files, workload identity, or local metadata services. Determine whether the earlier evidence suggests command execution or secret access. If it does, rotate the exposed signing material and provider credentials, revoke sessions or tokens derived from them where the product supports it, and check for their use from unusual places.

Do not rotate blindly before preserving evidence when a real compromise is suspected. Rotation changes the environment and can destroy useful context. Contain the gateway, snapshot the relevant state according to your incident process, preserve logs outside the host, then replace trust. For a routine precaution with no suspicious evidence, a planned key rotation may still be sensible, but label it as precaution rather than proof of compromise.

There is a calibrated stopping point. If the gateway was affected, custom flows were reachable, and useful telemetry is absent, the organisation cannot prove the negative. It can still install the fixed image, narrow access, rotate the most consequential exposed keys, improve independent logging, and document residual uncertainty. That is an honest closure, not a failed investigation.

## Access to a flow is access to a parser

Many teams treat custom AI workflows as low-risk configuration. The user is already logged in, the workflow lives near source code, and the output looks like prose. CVE-2026-90970 shows why that category is too soft.

A custom flow is executable configuration. It chooses agents and steps, carries instructions into parsers and model calls, and can trigger work against a repository. Even when every step is meant to be declarative, the implementation interprets those declarations through code. Giving someone permission to create flows therefore grants access to an input language and the components that interpret it.

The immediate control is already present in GitLab's documented settings: projects can disallow custom and external agents and flows. [GitLab says the setting can be changed under the project's AI-native features](https://docs.gitlab.com/user/duo_agent_platform/flows/custom/). Teams that do not use custom flows should turn that path off. Teams that do use them should make the permission intentional instead of inheriting it from a broad project role without review.

Separate creation from promotion where the workflow matters. A developer can draft a flow in a test project with limited credentials and a small network boundary. A reviewed flow can then be promoted to a production project through the same change controls used for CI configuration. This does not make every flow a security release. It does make the dangerous transition visible: a piece of configuration moves from experimentation into a service that can touch important code and systems.

Keep the test environment honest. If its gateway shares the same signing keys, model-provider credentials, internal routes, and persistent volumes as production, it is a second front door to the same room. Use distinct workload identities. Give the test gateway only the repositories and model endpoints it needs. Deny arbitrary outbound access when the feature can operate with an allowlist.

The computer still needs a way out for legitimate work. That route should be named. List the GitLab instance, model endpoints, telemetry destination, package mirrors, and any other required services. Then deny the rest at the network layer rather than asking the prompt sandbox to enforce a network policy it does not own. A template escape that lands in a process with nowhere unexpected to connect has less room to grow.

Apply the same rule to files. Mount only required certificates and configuration. Keep signing keys in a secret delivery mechanism rather than baking them into an image. Do not mount the container runtime socket. Use a read-only root filesystem where the application supports it, a non-root process identity, and a small writable area for known temporary work. These controls will not repair a vulnerable template engine. They reduce what an escape can become while the repair is being installed or before the next flaw is known.

The most important boundary is administrative. The people who can enable the platform, allow custom flows, change the gateway image, alter its secrets, and change its network policy should not collapse into one unreviewed group. A compromised developer account should not be able to submit the input, widen the route, and erase the evidence.

This is the practical meaning of least privilege for an AI gateway. It is not a vague instruction to “use fewer permissions.” It is a table that names each action, the identity allowed to perform it, the systems that identity can reach, and the evidence the action leaves behind.

## A repair sequence that closes the whole path

The order matters because an enthusiastic update can erase the container that held the best evidence. Use your established incident process when suspicious activity exists. For an ordinary exposure with no such signs, the following sequence produces a defensible repair without turning one CVE into a month-long programme.

1. **Confirm that you own the affected component.** Determine whether GitLab operates your AI Gateway or your team does. GitLab.com, GitLab Dedicated, and self-managed GitLab connected to GitLab's hosted gateway had already received the provider's fix, according to GitLab's advisory as reported on 2 October. A self-hosted AI Gateway is the deployment that needs local action.

2. **Record the running version before changing it.** Capture each container or pod, its immutable image digest, start time, deployment revision, and ready state. Compare the actual version with the affected ranges in the CVE record. Preserve this receipt with the change ticket so a later reviewer can tell which workload was exposed.

3. **Preserve evidence if anything looks wrong.** Save flow changes, relevant audit events, gateway and GitLab logs, container-runtime events, process telemetry, and network records outside the workload. If a gateway process spawned an unexpected command or reached an unexplained destination, contain it and follow the incident plan before destroying the container.

4. **Install a compatible repaired release.** Move to AI Gateway 19.2.4, 19.3.2, 19.4.1, or a later supported version. Confirm compatibility with the GitLab release rather than choosing a tag solely because its number is higher. If no supported fixed path exists for the current line, disable custom flows or isolate the gateway while GitLab support confirms the upgrade route.

5. **Prove every replica changed.** Record the digest of every ready workload after the rollout. Check for old replicas, stalled terminations, crash loops, and nodes still serving a cached image. Exercise the normal authenticated request path and the intended model connection. The desired manifest and the running set should agree.

6. **Review who could submit custom flows.** Enumerate projects with the platform enabled, the custom-flow setting, and the identities that could use it during the affected period. Disable custom flows where they are not needed. Move important flow changes through review rather than granting broad direct creation in production projects.

7. **Map and reset exposed trust where justified.** List signing keys, model credentials, workload identities, mounted configuration, and reachable internal services. Rotate credentials supported by suspicious evidence or whose exposure cannot be bounded. Preserve evidence first, and document whether each rotation was incident response or precaution.

8. **Narrow the host for the next flaw.** Restrict outbound routes to named services, remove unnecessary mounts, run without root where supported, keep the root filesystem read-only where practical, and send logs to a system the gateway cannot edit. Verify those controls from outside the container.

9. **Close with two receipts.** The change receipt should show the repaired image running on every replica and passing a health check. The security receipt should show the earlier access review, evidence sources checked, credential decisions, known gaps, and the owner of any follow-up. One proves the code changed; the other explains why the team believes trust has been restored.

This sequence is intentionally shorter than a generic hardening checklist. It follows the actual path disclosed in October 2026: authorised user, custom-flow configuration, prompt-template parser, gateway process, host authority. Controls that do not interrupt or observe that path can wait.

## What this changes for AI platform design

The most useful architectural lesson is that a semantic sandbox and a machine boundary do different jobs. A prompt-template sandbox decides what an expression may mean inside a template engine. A container, workload identity, file policy, and network policy decide what the resulting process may do to the environment. The second set should assume the first can fail.

Teams already understand this with web applications. Input validation does not replace database permissions. Escaping output does not replace browser isolation. A web template bug should not grant the web process ownership of backups and deployment keys. AI infrastructure deserves the same mature separation, even when its inputs are called flows and prompts instead of forms and fields.

The gateway also deserves its own asset record. Record its owner, supported release line, image source, secrets, inbound callers, outbound destinations, data stores, and logging path. Include it in vulnerability scanning and the patch calendar. A service that brokers model requests can otherwise disappear into the category of “AI configuration” and miss the operational controls applied to every other production service.

Self-hosting remains a reasonable choice. It can keep sensitive request and response data inside a controlled environment and support model arrangements that a hosted service does not. It does not transfer only privacy benefits. It transfers patching, isolation, observation, and incident decisions as well. That trade is worthwhile only when the receiving team accepts the whole package.

There is a useful test for future platform purchases: ask what happens after the product's inner sandbox fails. Which process identity receives execution? Which secrets can it read? Which destinations can it contact? Can it alter its own logs? Can the team name the running version without trusting a control panel? Clear answers matter more than a vendor diagram with a box labelled “secure sandbox.”

CVE-2026-90970 arrived with a direct repair and no published evidence of active exploitation as of 3 October 2026. That is a good moment to practice the full response without drama. Install the fix. Prove what is running. Review the people and projects that could reach the parser. Decide what trust the old process may have exposed.

The deeper rule is simple: if a prompt sandbox can fail into a host, the host must be safe enough to receive that failure. The Secure Harness develops that model for coding agents in more detail, but this incident gives it a compact operational form. Patch the parser, then collect the receipt from the machine beneath it.

If you want more security and AI engineering explained without the noise, the newsletter sends one email per month. The signup is on this site.

## Sources

- [GitLab / CVE Program: CVE-2026-90970 record](https://cveawg.mitre.org/api/cve/CVE-2026-90970), accessed 2026-10-03
- [The Hacker News: GitLab Patches Critical 9.9 AI Gateway Flaw Allowing Command Execution on Self-Hosted Servers](https://thehackernews.com/2026/10/gitlab-patches-critical-self-hosted-ai.html), accessed 2026-10-03
- [Security Affairs: CVE-2026-90970, Critical GitLab AI Gateway Flaw Fixed](https://securityaffairs.com/200283/hacking/cve-2026-90970-critical-gitlab-ai-gateway-flaw-fixed.html), accessed 2026-10-03
- [GitLab Docs: AI Gateway](https://docs.gitlab.com/administration/gitlab_duo/gateway/), accessed 2026-10-03
- [GitLab Docs: Self-hosted models](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/), accessed 2026-10-03
- [GitLab Docs: Use foundational and custom flows](https://docs.gitlab.com/user/duo_agent_platform/flows/), accessed 2026-10-03
- [GitLab Docs: Custom flows](https://docs.gitlab.com/user/duo_agent_platform/flows/custom/), accessed 2026-10-03
- [GitLab Docs: Install the GitLab AI Gateway](https://docs.gitlab.com/install/install_ai_gateway/), accessed 2026-10-03
- [GitLab Docs: Offline deployment](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/offline_deployment/), accessed 2026-10-03
- [GitLab Docs: Logs for self-hosted models](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/logging/), accessed 2026-10-03
- [GitLab Docs: Configure GitLab Duo](https://docs.gitlab.com/administration/gitlab_duo/configure/), accessed 2026-10-03

---

## About the author

Kubilay Tunca — Senior Full Stack Developer and Author. Founded Cyber Security in Plain English to translate complex security concepts into clear, practical advice, and writes the accompanying books on security, privacy, secure development, and AI systems.

## Books by this author

- **The Digital Fortress** — Your Everyday Guide to a Safer Digital Life. A warm, plain-English guide for people with real lives and finite patience. Learn the handful of habits that genuinely protect your money, accounts, and family, and get honest permission to ignore the rest. [Amazon](https://buy.cyber-security-in-plain-english.com/digital-fortress) · [Details](https://cyber-security-in-plain-english.com/books/the-digital-fortress)
- **The Anonymity Playbook** — Digital Survival for Whistleblowers, Journalists, Activists, and Everyone Else. A practitioner’s field manual for journalists protecting sources, whistleblowers, and activists. It explains how the surveillance actually works, what each technique costs you, and exactly where it fails. [Amazon](https://buy.cyber-security-in-plain-english.com/anonymity-playbook) · [Details](https://cyber-security-in-plain-english.com/books/the-anonymity-playbook)
- **Secure Software Development** — Practical patterns for building secure software. A hands-on security guide for developers and IT professionals who ship real software. Build, deploy, and maintain secure systems without slowing down or drowning in theory. [Amazon](https://buy.cyber-security-in-plain-english.com/secure-software-development) · [Details](https://cyber-security-in-plain-english.com/books/secure-software-development)
- **The Secure Harness** — Shipping Production Code with AI Coding Agents. A calm, practical guide to letting agents do useful work inside boundaries you set, enforce, and audit. Ships with 15 copy-pasteable artifacts: hook scripts, permission configs, release gates, and MCP templates. [Amazon](https://buy.cyber-security-in-plain-english.com/secure-harness) · [Details](https://cyber-security-in-plain-english.com/books/the-secure-harness)
- **The AI Native Engineer** — Build, Evaluate, and Ship AI Systems That Work in Production. Sixteen hands-on chapters, one real product. Grow it from a single model call into a retrieved, tool-using, observable, production-grade system, with evaluation treated as a habit from the first feature. [Amazon](https://buy.cyber-security-in-plain-english.com/ai-native-engineer) · [Details](https://cyber-security-in-plain-english.com/books/the-ai-native-engineer)

Full catalogue with contents and intended audience: https://cyber-security-in-plain-english.com/books

_As an Amazon Associate I earn from qualifying purchases. Buying through these links costs you nothing extra and helps pay for the blog._