[HIGH] YAML frontmatter --- escape produces invalid escape sequence
Location: src/pages/admin/posts.astro:119
The formatFrontmatter function in posts.astro and pages.astro attempts to escape --- sequences using content.replace(/^---$/gm, '\\-\\-\\-'). In JavaScript, '\\-\\-\\-' becomes the literal string \-\-\-. However, \-\-\- is NOT a valid YAML escape sequence—YAML only recognizes specific escapes like \n, \t, \", etc. The YAML parser will interpret \-\-\- as literal characters, which does not prevent --- from being recognized as a document separator. A user can still inject content that breaks out of frontmatter by starting their post with ---.
Suggested fix: Either check if content starts with --- and prepend a newline, or use proper YAML block scalar syntax. For example: if (post.content.startsWith('---')) content = '\n' + content;

[HIGH] YAML injection via unquoted date field in frontmatter generation
Location: src/pages/admin/posts.astro:127
In src/pages/admin/posts.astro, the formatFrontmatter function generates YAML frontmatter with an unquoted date field at line 131: date: ${post.date}. If post.date contains a newline character, it breaks out of the field value and allows injection of arbitrary YAML keys.

Example attack: setting date to 2024-01-01\nauthor: "injected" produces:

---
title: "..."
date: 2024-01-01
author: "injected"
---

This injects an additional author field into the frontmatter. The same vulnerability exists in pages.astro at line 109 with date: ${page.date || ...}.

Both locations should quote and escape the date value like: `date: "${escapeYAML(post.date)}"`.
Suggested fix: Quote and escape the date field: date: "${escapeYAML(post.date)}"

[HIGH] YAML injection via unquoted date field in pages frontmatter generation
Location: src/pages/admin/pages.astro:103
In src/pages/admin/pages.astro, the formatFrontmatter function at line 109 uses an unquoted date field: date: ${page.date || new Date().toISOString().split('T')[0]}. If the page's date value contains a newline, it injects arbitrary YAML structure. This is the same vulnerability as in posts.astro but affects page exports.

The date field should be quoted and escaped: `date: "${escapeYAML(page.date || new Date().toISOString().split('T')[0])}"`.
Suggested fix: Quote and escape the date field: date: "${escapeYAML(page.date || new Date().toISOString().split('T')[0])}"

[MEDIUM] Missing fallback for undefined date in formatFrontmatter
Location: src/pages/admin/posts.astro:131
The formatFrontmatter function inserts post.date directly without a fallback: date: ${post.date}. While the save function sets date: new Date().toISOString().split('T')[0], if post.date is undefined (from corrupted localStorage, manual edits, or API responses), this produces date: undefined which is invalid YAML syntax.
Suggested fix: Use a fallback: date: ${post.date || new Date().toISOString().split('T')[0]}

[MEDIUM] Config load/save asymmetry breaks token restoration
Location: src/pages/admin/deploy.astro:302
The save-config function explicitly omits the token from the exported JSON for security reasons (line 252-255), but the load-config function only checks for config.cloudflare.token (lines 302-306). This creates two problems:

1. Saved config files can never restore the API token — the user must re-enter it every time
2. Old config files using the flat config.token format are not supported for token restoration

The result is that after exporting a config, users cannot re-import their API token. The load function needs a fallback check for config.token (the old flat format) to provide backward compatibility for users with existing config files.
Suggested fix: Add a fallback to load token from old flat format: const token = config.cloudflare?.token || config.token; and then restore it to localStorage.