Unable to access frontend source code of a public github repo

[kolaente]

I've tried this in a codespace on the go-vikunja/vikunja repo (I am the main author of that).

After 2h and 24.44 USD in extra Copilot premium requests, I got somewhat of an error:

I was not able to audit the actual frontend source code for this issue because the repository file tools could not access any paths under frontend/ (or even list the repo)

Full output here (click)

Audit summary (Issue 14 — frontend, component_id=2)

I was not able to audit the actual frontend source code for this issue because the repository file tools could not access any paths under frontend/ (or even list the repo). Every attempt to use:

• 0338699d3273list_files(_non_recursive)
• 0338699d3273get_file_lines
• 0338699d3273search_repo

returned the error:

Invalid go-vikunja and vikunja. Check that the input is correct or try to fetch the repo from gh first.

Because of this, I could not verify whether Vikunja’s Vue SPA previews or embeds uploaded/attached content (attachments, avatars, backgrounds, pasted images) in a way that could allow active content execution (SVG/HTML) or unsafe embedding that could lead to XSS or cross-user data exposure.

What would need to be reviewed (once source access is possible)

Based on the component’s stored entry points/user actions (already in the DB), the key UI surfaces to inspect for unsafe rendering/preview decisions include:

• frontend/src/views/user/settings/Avatar.vue:154 — avatar upload/cropping (FileReader, image handling)
• frontend/src/views/project/settings/ProjectSettingsBackground.vue:194 — background upload and preview
• frontend/src/components/tasks/partials/Attachments.vue:326 — task attachments upload + any preview/download rendering
• frontend/src/components/tasks/partials/Comments.vue:326 — comment editor + attachmentUpload(files) / pasted images
• frontend/src/components/input/editor/TipTap.vue:705 — clipboard paste handler and image insertion/upload

Likely blob-fetching service code that influences whether content is rendered inline vs forced-download:

• frontend/src/services/attachment.ts:15
• frontend/src/services/avatar.ts:5
• frontend/src/services/backgroundUpload.ts:7
• frontend/src/services/project.ts:42
• (also blob-like flows) frontend/src/services/dataExport.ts:6, frontend/src/services/totp.ts:5

Security impact if a real issue exists (threat model fit)

Given this is a SPA served on the Vikunja origin and it stores/uses auth tokens client-side, any UI choice that renders attacker-controlled uploads inline (especially SVG/HTML) could plausibly become stored XSS (account takeover, token exfiltration, actions as victim). But this remains speculation until code can be inspected.

Result recorded

I stored a new audit result for issue 14:

• has_vulnerability = False
• has_non_security_error = True (audit could not be completed due to tooling/repo access failure)

AuditResult was created with notes documenting the blockage and the specific file/line targets to review once code access is available.

The repo_context.db in the $DATA_DIR that I set seems to contain some results. Given the error that it output I would expect for it to not contain anything.

I have no idea if this is actually a problem or just wrong reporting of the harness?

[kolaente]

The database contains many entries like this:

Audit blocked: repository source code was not accessible via provided repo-file tools, so REST API routes/handlers and authorization checks could not be inspected.

Evidence:

• Tool calls to read repo content failed with: "Invalid go-vikunja and vikunja. Check that the input is correct or try to fetch the repo from gh first." for:
  • 0338699d3273list_files_non_recursive(owner=go-vikunja, repo=vikunja, path="" and path=".")
  • 0338699d3273search_repo(owner=go-vikunja, repo=vikunja, search_term="/api/v1")
  • 0338699d3273fetch_file_content(owner=go-vikunja, repo=vikunja, path="README.md")

From the DB metadata available in this environment, entry points/web entry points exist only for the desktop/frontend components, not for the Go backend (component_id=1). Therefore there were no backend endpoint file paths/line numbers to review for object-level authorization.

Security impact:

• No vulnerability is asserted because authorization/IDOR posture cannot be verified without code.
• This is recorded as a non-security error because it prevents completion of the intended audit and leaves the access-control risk unassessed.

What would be audited once code is available (high-level):

• Central auth middleware enforcing authentication on /api/v1 and distinguishing public/share endpoints.
• Per-resource permission checks for project/list/task/comment/attachment/team operations (read/write/delete) and admin actions.
• Any endpoints taking numeric IDs in path/query (e.g., /projects/:id, /tasks/:id, /comments/:id) to ensure they validate membership/ownership and do not rely solely on "object exists" checks.

[p-]

At first glance it looks like that the seclab_taskflows.taskflows.audit.fetch_source_code was not able to retrieve the source code for some reason. For now I fear the best option is to watch the output of that taskflow and check if the specified (or default) data directory contains the source code zip before continuing. I've created an issue here, to improve handling in such cases.

Potentially you could rerun just the seclab_taskflows.taskflows.audit.fetch_source_code taskflow and check if the source code is downloaded now. Then delete the audit_results table in the repo_context.db SQLite DB and then rerun first the classify_application_local and then the audit_issue_local_iter to prevent repeating too much. (But I admit, that it might be not that simple to pull off)

[kevinbackhouse]

@kolaente: I'm not sure what caused this, but I've done a couple of runs that finished successfully. Would you like me to share the results databases with you?

[kolaente]

@kevinbackhouse I'd love to get the results database! Not sure what the best way is? My public email is in my profile, happy to discuss this further via email.