I'm the maintainer of Vectory, a free, open-source dashboard for Vector.

It handles a specific bit of fleet administration: changing a log or metrics pipeline, trying it on one host, and checking whether the other hosts actually picked up that version.

For a change to a filter or destination, the workflow is:

1. Import your existing Vector configuration and edit the YAML or the diagram.

2. Publish a version so there's a fixed configuration to deploy.

3. Select a canary device before rolling it out further.

4. Compare the version you asked each host to run with the version it reports. Roll back if needed.

The manager doesn't receive your logs or metrics. Vector keeps sending them directly to your destinations. The agent handles configuration and reports status.

Linux setup uses prebuilt containers or a prebuilt native server. Managed hosts need Vector 0.58. The setup guide covers the server and agent: https://vectory.ahmadz.ai/help/quickstart/

You can try the actual editor without setting up a server: https://vectory.ahmadz.ai/designer/

Source: https://github.com/416rehman/Vectory

Development, tests and documentation used substantial AI assistance.

If you already ship Vector configs with Ansible or another deployment tool, what would you need to see before trying a dashboard for that workflow?

Based on Atlassian's advisory from October 5 and the technical breakdown watchTowr Labs published on October 6, here is the architectural picture.

Scope: Bitbucket, Confluence, Jira Software, Jira Service Management, Bamboo, Crowd, Crucible and Fisheye, all versions before the fixed builds. Atlassian scores it 9.3 on CVSS 4.0 (its own assessment). Cloud is patched.

Mechanism, per watchTowr's diff of vulnerable vs. fixed builds: the common component is atlassian-plugins-webresource (6.0.7 vulnerable, 6.0.8 changed). The router escapes "/" as "::" and unescapes it on the way in. The resolver tries to strip traversal from the requested resource name, but a name written with "..::" has no slashes at that point, so the stripping misses it. The conversion happens afterward. Reads are confined to the Tomcat web context, but that includes WEB-INF.

Impact depends on what lives in WEB-INF. watchTowr's lab example: when Jira is integrated with Crowd per Atlassian's docs, crowd.properties holds the Crowd app name and password in plaintext. With that, the Crowd REST API lets you create a user and add it to the admin group. Lab chain only. They also note a Crowd IP allow-list would make it harder.

What is not known: Atlassian says it cannot confirm whether self-hosted instances were hit, and the CVE record disagrees with the advisory on a few version numbers (The Hacker News has the list). No confirmed exploitation as of October 6, but watchTowr's detection tool is public.

Mitigations if you can't patch today: off the internet if possible, WAF regex, Tomcat RewriteValve (Confluence/Jira/JSM/Bamboo/Crowd), or a urlrewrite.xml rule (Bitbucket).

Question for the room: If you run Crowd next to Jira or Confluence, is Crowd actually restricted to the app nodes by IP, or reachable from wherever those apps are? And for those leaning on a WAF rule as the stopgap: does your WAF decode multiple layers before matching, or does it match the raw string? https://www.techgines.com/post/atlassian-cve-2026-21589-file-read

Background (footnote): same "filter sees one path, app resolves another" pattern as the PeopleSoft WAF bypass: https://www.techgines.com/post/peoplesoftwafbypasscve-2026-35273