Linkblog

A Long Day for PHP Admins

Thu, 22 Oct 2026 00:00:00 +0000

Yesterday, two critical security vulnerabilities in PHP dubbed “php2shell” were publicly disclosed: CVE-2026-109618 and CVE-2026-109619. Both could allow attackers to execute code on vulnerable servers without authentication. With no reliable mitigation available other than updating PHP, we made the decision to temporarily take all our and our customers’ hosted services offline as a precaution.

Now, a day later, it’s time to reflect and see what we learned.

CosmoCode Services are back up

All the PHP services, including the wikis we host, are back up and running the new PHP versions released yesterday.

The official PHP security advisory with details was released at 14:00 UTC. With it, new PHP versions were made available.

Updated PHP packages for Debian (our preferred Linux distribution) followed shortly after, and we began updating and restarting the first services.

The official Docker packages took a couple of hours to arrive at Docker Hub. About 20 minutes later, new DokuWiki Docker images were released.

Around 19:30 UTC (21:30 German time), all our systems were back to normal.

I want to thank my colleagues Karsten and Tilo, who worked with me until such a late hour. I also want to thank the many, mostly unpaid volunteers, in the involved Open-Source communities making this quick turnaround possible!

Was it necessary?

As always, when a catastrophe has been prevented, the question arises whether there would actually have been one in the first place.

When the first information about the vulnerability came out, no concrete details were known. It was not clear whether any mitigation was available, and the only information we had was a Mastodon post by PHP core developer Gina Peter Banyard:

The only thing I can say is that the only mitigation is patching / upgrading PHP. I sadly know too much.

At the same time, Cloudflare reported that they had seen and blocked patterns that looked like attempts to exploit the vulnerability (or what little was known about it) at the time. It seemed that at least parts of the vulnerability were already known and were being actively exploited.

This is why we decided on the drastic measure of taking the services offline. We were not alone in that assessment, and many other small and large organizations followed suit during the day.

With the full details now known, it seems that actually exploiting the vulnerability is a bit more difficult than initially assumed. So the big wave of automated break-ins that was feared most has not materialized yet. Nonetheless, we are already seeing probing attempts for the CVEs in our CrowdSec web application firewall logs.

Will it happen again?

The PHP Foundation’s write-up on the issue is a good read. Basically, the threat was vaguely known for a long time, but it was difficult to assess whether and how it could be exploited at all, especially with the limited resources available to an open-source project.

AI is changing the landscape here. All Internet-facing software is under constant scrutiny now. AI labs are spending trillions of tokens to proudly proclaim that they were the ones who found a serious vulnerability and thus made the net “safer”. Which is both true and false at the same time.

AI is also giving attackers a new tool to exploit known vulnerabilities, beyond their own skills. Trying to keep issues under wraps and coordinate disclosure, as we saw yesterday, is becoming harder and harder. Even yesterday’s release was already a deviation from the original release plan, because knowledge of the issue had leaked during the embargo. And often the rumor of a vulnerability is now enough to have LLMs reproduce it independently and generate working exploits.

So more serious vulnerabilities will be found, and the notice periods may become even shorter. Drastic measures like the ones we saw yesterday might very well become more common.

What is CosmoCode doing?

With this new reality, we need to be prepared for next time. Luckily, we have been improving our infrastructure management over the last couple of years, moving most of our services to a Kubernetes cluster managed by us. This new infrastructure proved invaluable for the fast reactions and updates we were able to deliver yesterday.

But we also learned a few lessons:

Not all our updates in the cluster were as frictionless as we would have liked, and we might need to improve the way we can quickly identify all services running a specific technology. This could be a programming language, as was the case yesterday, or a specific library or framework in the future. There are also some legacy systems left that should be migrated.

We also need to improve our processes for quickly notifying affected customers. For our wiki customers, it was easiest for me to quickly send a newsletter.With the added benefit that this also informed those whose wikis we’re not hosting. But others had to be contacted individually.

If you need help preparing for the next security incident or have other technical challenges, feel free to get in touch with us. We’re happy to discuss how we can help.

Ein KI-Agent, der Ihre Software von innen kennt

Wed, 30 Sep 2026 00:00:00 +0000

Ein KI-Agent, der Ihre Software von innen kennt

In der Softwareentwicklung arbeiten wir täglich mit KI-Agenten und wissen, wie nützlich diese Werkzeuge sein können. Doch auch in anderen Bereichen sind diese Systeme nützlich. Unser Wiki zum Beispiel hat einen eingebauten Agenten. Er beantwortet Fragen mit Wissen aus dem Wiki und mit Daten aus unserer übrigen internen Software. Für einen Kunden haben wir ein ähnliches System gebaut, das komplexe Auswertungen aus der Vertragsdatenbank erstellt.

Da lag die Idee nahe, einen solchen Agenten in jede Webanwendung einzubauen, die wir für unsere Kunden betreuen: ins TYPO3-CMS genauso wie in individuell entwickelte Fachanwendungen. Überall dort, wo Mitarbeitende im Backend Inhalte und Daten pflegen.

Das Ergebnis ist James - Ihr Butler fürs Backend.

Ein kurzes Video, das James vorstellt.

Was ist James?

Wir schreiben nicht nur Software für unsere Kunden, sondern unterstützen sie auch im laufenden Betrieb der Anwendung. Denn egal, wie gut die Software ist: Im Betrieb ergeben sich Fragen. Hier setzt James an. James ist ein Chat-Assistent, der direkt in die Anwendung eingebaut ist und dort hilft, wo gearbeitet wird: im Backend. Er ist für die Menschen gedacht, die sich in der Anwendung anmelden, um Inhalte und Daten zu pflegen, zum Beispiel den Redakteur:innen in einem CMS.

James ist also kein Chatbot für die Besucher:innen der Website. Wer die Seiten liest oder im Shop einkauft, bekommt ihn nie zu sehen. Er ist für die Menschen da, die mit der Anwendung arbeiten, nicht für die, die sie von außen nutzen.

James hat Werkzeuge, um den Quellcode der Applikation zu lesen, und kann in die Live-Datenbank schauen. Zudem kann er über den Browser der angemeldeten Nutzer:in “sehen”, was dargestellt wird. Zudem lassen sich weitere Informationen wie das Nutzerhandbuch oder Fachwissen hinzufügen. Damit hat James dieselben Werkzeuge zur Verfügung, die auch wir nutzen würden, um eine Anfrage zu beantworten.

Wichtig ist dabei, dass der Agent nichts “kaputt” machen kann. Er darf zwar den Quellcode und die Datenbank lesen, hat aber keine Werkzeuge, um Änderungen durchzuführen. Gegebenenfalls kann er natürlich erklären, wie eine Anpassung durch die Nutzer:in selbst vorgenommen werden kann.

Wofür ist das gut?

Das Tolle an Agentensystemen ist, wie flexibel sie mit nur einer Handvoll Werkzeugen einsetzbar sind. Für James ergeben sich einige Anwendungsfelder.

Direktes Hilfesystem

Fragen zur Bedienung und zum Zustand der Applikation sind die naheliegendsten Aufgaben.

“Wie lege ich eine neue Veranstaltung an, die nur für angemeldete Mitglieder sichtbar ist?”
“Warum erscheint mein Artikel von gestern nicht auf der Startseite?”
“Wie kann ich einer Kollegin Schreibrechte für den Pressebereich geben?”
“Warum hat Bestellung 4711 noch keine Rechnung bekommen?”

James bietet hier eine direkte Zeitersparnis. Statt sich auf der Suche nach der richtigen Stelle durch die Anwendung zu klicken oder am Ende sogar bei uns nachfragen zu müssen, kann James die Antwort direkt liefern.

Spontane Auswertungen

Oftmals möchte man etwas über die Daten in der eigenen Software wissen, das über die Oberfläche in dieser Form nicht ausgegeben wird.

“Welche Kunden haben im letzten Jahr mehr als dreimal bestellt, aber seit sechs Monaten nicht mehr?”
“Wie hat sich die Zahl der Neuanmeldungen pro Monat seit Januar entwickelt, getrennt nach Region?”
“Welche Seiten wurden seit über zwei Jahren nicht mehr bearbeitet und von wem stammen sie?”
“Wie viele Verträge laufen im nächsten Quartal aus und welchen Umsatz machen sie zusammen aus?”

James kann die Daten dabei nicht nur zusammensuchen, sondern über eine eingebaute Bibliothek für Balken- und Liniendiagramme auch gleich grafisch darstellen.

James ist dabei für die schnelle Frage zwischendurch gedacht, nicht als Ersatz für ein richtiges Auswertungswerkzeug. Zeigt sich, dass eine Auswertung immer wieder gebraucht wird, ist es sinnvoller, die Anwendung entsprechend zu erweitern.

Der große Überblick

Eine eingebaute Bibliothek für Schaubilder (Mermaid) erlaubt es James, auch mal eben Datenflüsse oder Zusammenhänge grafisch zu visualisieren.

“Zeig mir, welche Schritte eine Bestellung vom Warenkorb bis zum Versand durchläuft.”
“Welche Rollen gibt es im System und wer darf was?”
“Wie hängen Produkte, Kategorien und Angebote zusammen?”
“Was passiert alles, wenn sich jemand für den Newsletter anmeldet?”

Fehlermeldungen und Änderungswünsche

Keine Software ist perfekt und manchmal stoßen unsere Kunden auf unvorhergesehene Probleme. James kann das Problem analysieren und einen technischen Bericht für CosmoCode erstellen - egal, ob es sich um einen Fehler oder eine fehlende Funktion handelt.

Wir sparen Zeit bei der Analyse des Problems und unsere Kunden Geld, weil die Fehlerbehebung schneller geht.

Software

James ist in Go geschrieben und enthält in einem einzigen Programm alles, was nötig ist: einen eigenen Webserver, das Backend, welches die Werkzeuge bereitstellt und mit dem Sprachmodell (LLM) spricht, sowie das Frontend für die Ausgabe. Dazu gehört eine Konfigurationsdatei, die festlegt, wo der Quellcode und andere Informationsquellen zu finden sind und wie die Datenbank anzusprechen ist.

Dieser Aufbau macht James unabhängig von der Programmiersprache und dem Framework der eigentlichen Anwendung, die es zu unterstützen gilt. Egal, ob ein PHP-basiertes TYPO3 oder eine individuelle Django-App: Am Ende muss nur ein kleiner JavaScript-Schnipsel integriert werden, und James steht allen authentifizierten Nutzer:innen zur Verfügung.

Die Konfiguration und Integration übernehmen wir natürlich.

Was noch kommt

Hat man James erst einmal im Einsatz, ergeben sich schnell neue Ideen. Mit weiteren Datenquellen könnte James zum Beispiel auch solche Fragen beantworten:

“Welche Seiten werden am häufigsten besucht, sind aber seit Jahren nicht aktualisiert worden?” (mit Daten aus Matomo oder Google Analytics)
“Bei welchen Suchbegriffen verlieren wir gerade Plätze bei Google?” (mit Daten aus der Google Search Console)
“Welche Kunden aus dem Shop haben ein offenes Ticket im Support-System?” (mit Anbindung an weitere Systeme)

Welche Erweiterungen wir zuerst umsetzen, entscheiden die Rückmeldungen unserer Kunden. Sie haben eine Idee oder möchten James in Ihrer Anwendung ausprobieren? Sprechen Sie uns an!

Jaw literally dropped. I ran the prompt from the "Made entirely with Opus 5. ...

Fri, 25 Sep 2026 06:03:47 +0000

My HTML Boilerplate

Fri, 11 Sep 2026 05:41:29 +0000

When HTML was first created, a document could be very simple indeed. A valid document could look like this:

<TITLE>HTML document</TITLE>
<H1>Heading</H1>

<P>This is a paragraph with a <A HREF="https://example.com/">link</A>.

It wasn’t until HTML 2.0 – the first formalised standard – that a proper document structure came into being. A DOCTYPE declaration to explain a document’s type and to handle compatibility became an expected inclusion, as did head and body sections:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

<HEAD>
    <TITLE>HTML document</TITLE>
</HEAD>

<BODY>
    <H1>Heading</H1>
    <P>This is a document.
</BODY>

In the years since HTML 2.0’s 1995 debut, the web has changed massively. However, there is a saying in the web standards world: ‘Don’t Break The Web’. There are some exceptions, but on the whole a website developed at the web’s inception should work in a modern browser, regardless of how much time has passed. To keep this compatibility, however, risks making changes impossible for fret of breaking existing sites.

One way the web combats this is with certain elements that are expected in HTML documents. If the element is present, then it uses the new functionality. If not, it simply falls back to the old functionality. Pair that with what different integrations and systems across the web expect, and it means that there is rather a lot of ‘boilerplate’ – code that is repeated across almost every new or maintained site. HTML boilerplate commonly both opts in to modern functionality and also sets site preferences and details. Assorted things such as how the site should embed on social media, what styles should be loaded, how the browser should theme surrounding the site, and other such details.

Boilerplate

Much like I maintain my own CSS reset, which provides me a clean slate for my styles, I maintain my own boilerplate, which I use as a base structure and reference when creating HTML documents. Much like my CSS reset, it is very opinionated. Here it is in full:

<!doctype html>
<html lang="en">
	<head>
		<meta charset="UTF-8">
		<meta name="viewport" content="width=device-width">
		<meta name="text-scale" content="scale">
		<title>Name of Page | Name of Website</title>

		<link rel="stylesheet" href="/styles.css">

		<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>

		<meta property="og:title" content="Name of Page">
		<meta name="description" content="Description of this page.">
		<meta property="og:description" content="Description of this page for embeds.">

		<link rel="icon" type="image/svg+xml" href="https://example.com/favicon.svg">

		<meta property="og:image" content="https://example.com/embed-image.webp">
		<meta property="og:image:alt" content="A picture of something.">
		<meta property="og:image:type" content="image/webp">
		<meta property="og:image:width" content="1200">
		<meta property="og:image:height" content="630">

		<link rel="canonical" href="https://example.com/page">
		<meta property="og:url" content="https://example.com/page">

		<meta property="og:site_name" content="Website Name">

		<meta name="author" content="A N Other">

		<meta name="color-scheme" content="light dark">
		<meta name="theme-color" content="red" media="(prefers-color-scheme: light)">
		<meta name="theme-color" content="green" media="(prefers-color-scheme: dark)">

		<link rel="alternate" type="application/rss+xml" title="RSS feed of posts on Website Name." href="/posts/feed.xml">
		<link rel="alternate" type="application/feed+json" title="JSON feed of posts on Website Name." href="/posts/feed.json">

		<link rel="search" type="application/opensearchdescription+xml" title="Website Search" href="https://example.com/opensearch.xml">
		<link rel="manifest" href="/app.webmanifest">
	</head>

	<body>
		<header><nav></nav></header>
		<main id="main"></main>
		<footer id="footer"></footer>
	</body>
</html>

Breakdown

It should be noted that there is order to my HTML boilerplate. The order of the document head in particular has great influence on performance. Capo.js is a brilliant tool for evaluating the order of elements in a document’s head from a performance perspective.

<!doctype html>

This is the document type declaration for the living HTML standard, as introduced in HTML 5. I always include it to avoid falling into quirks mode.

<html lang="en"></html>

Opens the html tag which wraps the document and defines the document language using an RFC 5646 compliant tag with the lang attribute. The language provided the default for the full page and can be overwritten on a per-element basis. Providing the language is important for automatic translation, typography such as hyphens, and for assistive technologies (especially screen readers).

<meta charset="UTF-8">

The first element I place in the head is always the charset meta tag with a value of UTF-8, which is the only valid encoding as of HTML 5. It is always top of the head, as it must occur within the first 1024 bytes of a document, and it should be before any elements liable to get mangled.

<meta name="viewport" content="width=device-width">

When the first iPhone launched in 2007, it rendered desktop sites with the expectation of the user to zoom in and pan around. Apple introduced the above meta tag for sites that were actually optimised for mobile, and it was eventually picked up more widely across browsers such that now it is supported widely to make a site responsive.

Many people will include initial-scale=1, however, after extensive testing and research, I’ve identified that it isn’t necessary to include any more. It can be included to change the page’s presentation if an element horizontally expands beyond the viewport width, but that should never be allowed to happen and I advise against it.

minimum-scale, maximum-scale, and user-scalable all greatly harm accessibility and should never¹ be used. They should generally be stripped from sites whenever noticed.

<meta name="text-scale" content="scale">

Makes text scale in accordance with the system setting. If this tag is present, then a page’s styles must expect it and be written accordingly. This is especially important to avoid accessibility pitfalls with content scaling.

<title>Name of Page | Name of Website</title>

The title of the page. It is a required value which is shown on many surfaces. It is used as the name of the page when bookmarked, the name of the tab in search engines, and anywhere else a name for the page is needed. I’ll generally show the page title followed by the site’s title.

<link rel="stylesheet" href="/styles.css">

Whatever styles must be imported can be imported here. Styles should generally be imported in the page head rather than using the @import CSS at-rule within a stylesheet to avoid a waterfall, where the stylesheet must first be fetched to then fetch additional stylesheets.

<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>

Complex variable fonts can be rather large in size, even after subletting and other optimisations, so I preload fonts that I know will be used on the page. Even if a font is located on the same-origin, the crossorigin attribute is still necessary. I always serve fonts as WOFF2, as it is the most performant widely supported font format.

<meta property="og:title" content="Name of Page">

The og:title is used for embeds, such as those seen on social media. It is one of the many metadata values of the Open Graph protocol. While I’ll typically include the site name at the end of the <title> element, I leave it absent in the og:title. In the majority of cases embeds will show the domain or og:site_name next to the title, rendering it a duplicate.

<meta name="description" content="Description of this page.">

I mainly treat this meta description field as an exercise in search engine optimisation. Previously major search engines would expose the description to users on search pages, however they mostly fetch directly from the document itself now.

<meta property="og:description" content="Description of this page for embeds.">

The og:description is sometimes shown in embeds. If absent, embeds usually forgo a description or fall back to the meta description. I like to write short, often quippy content here that strikes intrigue and fits in social media or chat feeds.

<link rel="icon" type="image/svg+xml" href="https://example.com/favicon.svg">

A favicon is an important bit of branding for all websites – especially when it comes to identifying tabs when you have many open. I serve favicons as SVGs, as they’re well supported, can be made to dynamically adapt to light/dark mode, look good at all sizes, and remove the need for maintaining a set of raster favicons in different sizes.

<meta property="og:image" content="https://example.com/embed-image.webp">
<meta property="og:image:alt" content="A picture of something.">
<meta property="og:image:type" content="image/webp">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">

The image defined in the og:image is often shown in a site’s embed on the likes of social media or chat platforms. It is advantageous to include on almost every site, as it adds context and usually increases an embed’s size for better presence. Support for alt text on embedded images is middling, so it shouldn’t be relied upon. Some sites support it, some ignore it, and some support it in odd ways. I make the effort to include it but keep it brief. 1200px by 630px is a widely supported size, and WebP is the best supported of the modern image formats I’ve tested.

<link rel="canonical" href="https://example.com/page">
<meta property="og:url" content="https://example.com/page">

A canonical link to the authoritative version of the page is important for indicating what should be considered the source of truth. This is especially important if content is duplicated.

<meta property="og:site_name" content="Website Name">

The name of the website to be shown in embeds. As aforementioned, some embeds will show this name near the page’s title.

<meta name="author" content="A N Other">

The author tag obviously indicates the author of a page. It isn’t strictly necessary but is useful for developers to identify who is responsible for a page.

<meta name="color-scheme" content="light dark">

Setting the color-scheme meta tag with a content attribute value of light dark tells the browser that a site supports both light and dark modes. Having it defined in the head prevents a Flash of Unstyled Content (FOUC), such as a screen of bright white when the site and browser are set to dark mode.

<meta name="theme-color" content="red" media="(prefers-color-scheme: light)">
<meta name="theme-color" content="green" media="(prefers-color-scheme: dark)">

Used for theming the browser chrome of sites installed as progressive web apps (PWAs) and for theming the browser chrome in Chrome for Android (but only in light mode). Some other browsers also interpret these values in various ways. I use the media attribute to set the colour independently for both light and dark modes.

<link rel="alternate" type="application/rss+xml" title="RSS feed of posts on Website Name." href="/posts/feed.xml">
<link rel="alternate" type="application/feed+json" title="JSON feed of posts on Website Name." href="/posts/feed.json">

If a site has syndication feeds, then including these in the head permits autodiscovery of them.

<link rel="search" type="application/opensearchdescription+xml" title="Website Search" href="https://example.com/opensearch.xml">

If a site has integrated search functionality, then establishing an opensearch.xml file and referencing it from your document head exposes it to browsers so they can provide a rich searching experience. The exact experience differs by browser, but in many cases it allows searching with a site via the browser’s own address bar and also provides a simple way to add a search engine.

<link rel="manifest" href="/app.webmanifest">

I’m a progressive web app evangelist. I love them, and many sites benefit from being PWAs, even if a site is not a typical ‘app’. I’ll define a manifest for most sites even if the only benefit is that the presentation is nicer if people add the site to their homescreen. This declaration helps browsers discover the manifest.

<header><nav></nav></header>
<main id="main"></main>
<footer id="footer"></footer>

This defines any site’s general body structure. The header holds a navigation element for general site navigation. The main holds the primary page content and has an id attribute to provide an anchor, which is important for ‘skip to’ links. The footer holds information about the current site and page. Like main, I give it an id for anchoring purposes. I don’t get any more detailed with my HTML body boilerplate, as there is so much variance depending on the site.

This is just boilerplate. It is a template for what I’ll include on roughly every site, with some light alterations. Every site is sure to deviate from this depending on its requirements, but this is a reasonable foundation.

If a page is expected to be cited academically, then you’d consider including Google Scholar’s citation_* meta tags and Dublin Core’s dc meta tags. If a page represents an article, then you’d include the tags from the Open Graph Protocol’s article namespace and perhaps tags pertaining to a publishing system. A video, audio, book, or other content type would similarly be marked up differently. Many sites will also benefit from JSON-LD structured data. It all depends on the particular page and what is needed.

For a larger boilerplate that outlines some more optional inclusions, I recommend Manuel Matuzović’s brilliant article, My HTML boilerplate in 2026.

There are cases where they can be used, but you’ll know those extremely rare cases when you come to them. Take great and extreme care. ↩

Index of Aesthetics

Sat, 22 Aug 2026 21:45:24 +0000

Search and filter by...

Keyword

Earliest Known Example

and

End of Popularity

and

Relevant Decade