onedev BOPLA Vuln Reports

• All Issues illuastrated in this page has been acknowledged by the proj owner

• 
  
  Issue 01 — Unauthorized Cross-Project Repository Fork via forkedFromId

Risk Summary

A user who is allowed to create projects within a namespace may be able to create a fork project whose forkedFromId references a source project the user should not be able to read.

The affected workflow appears to copy repository data, LFS objects, commit metadata, and project avatar information from the source project into the attacker-controlled target project without enforcing source-project read authorization.

Because newly created projects automatically grant Owner-level authorization to the creator, the attacker may subsequently grant themselves repository read access and retrieve the copied repository contents through normal repository APIs.

In practice, this may allow unauthorized cross-project replication of private repository contents and related metadata.

Affected Entry Point

• POST /projects

Key Property

• project.forkedFromId

Core Observation

The project creation path validates whether the caller may create a project under the target parent namespace, but we did not observe equivalent authorization checks ensuring that the caller may access or read the source project referenced by forkedFromId.

The downstream fork implementation subsequently performs repository mirroring and metadata cloning directly against the supplied source project object.

Suggested Remediation

• Require explicit source-project visibility and/or code-read authorization before accepting forkedFromId.

• Add defensive verification inside the actual fork service implementation as well.

• Add regression tests for:

  • “user may create project”

  • but “user may not read source repository”.

Maximum Potential Impact

If exploitable, a user who should not be able to read a private repository may still replicate the repository contents and related metadata into a project fully controlled by the attacker.

---

Issue 02 — Unauthorized Parent Project Rebinding via parentId

Risk Summary

A user who can manage a project may be able to change the project's parentId to another parent namespace where the user does not possess CreateChildren permission.

Once the parent relationship changes, the project path, ancestor hierarchy, inherited settings, and permission propagation chain may all change accordingly.

This issue primarily affects project hierarchy integrity and namespace-boundary enforcement.

Affected Entry Point

• POST /projects/{projectId}

Key Property

• project.parentId

Core Observation

The request-processing order appears to overwrite the existing parent relationship before the old parent ID is captured for comparison, causing the subsequent permission check to compare the new parent against itself and skip the intended CreateChildren authorization validation.

The downstream update logic then recalculates and persists the new project hierarchy and path structure without additional authorization verification.

Suggested Remediation

• Preserve the original parent relationship before mutating the entity.

• Perform authorization checks before applying the new parentId.

• Add defensive validation in downstream project-update logic.

• Add regression tests for:

  • “user may manage project”

  • but “user may not create child projects under target namespace”.

Maximum Potential Impact

If exploitable, an attacker may silently move projects into unauthorized namespaces and alter hierarchy inheritance and permission propagation boundaries.

---

Issue 03 — Default Branch Modification Protected Only by WriteCode

Risk Summary

The REST API for changing project.defaultBranch currently appears to require only WriteCode permission.

However, the default branch acts as a project-level control-plane attribute influencing workflow automation, branch selection logic, and default execution targets.

The current Web UI already restricts this operation to project-management-level capability, resulting in inconsistent authorization semantics between UI and REST paths.

Affected Entry Point

• POST /repositories/{projectId}/default-branch

Key Property

• project.defaultBranch

Core Observation

The REST endpoint validates only canWriteCode(project) before directly updating the default branch.

We did not observe equivalent canManageProject(project) enforcement along this path.

Suggested Remediation

• Align REST authorization semantics with Web UI behavior.

• Require canManageProject(project) (or equivalent elevated control-plane permission).

• Review other project-level control attributes for similar permission inconsistencies.

Maximum Potential Impact

A user who is intended only to modify repository contents may also influence workflow automation and default branch execution behavior across the project.

---

Issue 04 — Pull Request Modification Capability Delegation via Arbitrary Assignee 

Rejected by the developer

 

Issue 05 — Unauthorized Exposure of Time-Tracking Information via Issue REST APIs

Risk Summary

Issue time-tracking information appears to be exposed through REST APIs to users who may access the issue itself, even when those users do not possess dedicated time-tracking visibility permission.

Exposed information includes both aggregated time statistics and detailed work-log entries.

Affected Entry Points

• GET /issues/{issueId}

• GET /issues/{issueId}/works

Affected Properties

• issue.totalSpentTime

• issue.ownEstimatedTime

• issue.ownSpentTime

• issue.progress

• issueWork.minutes

• issueWork.note

• issueWork.date

• issueWork.user

Core Observation

The REST paths validate only canAccessIssue(issue) before returning issue objects and work-log collections.

However, other service-layer and UI paths already appear to enforce dedicated canAccessTimeTracking(...) restrictions, indicating inconsistent authorization semantics between REST and non-REST access paths.

Suggested Remediation

• Require canAccessTimeTracking(project) before returning time-tracking fields or work-log entries.

• Hide or omit time-tracking fields when the caller lacks corresponding permission.

• Align REST behavior with existing UI/service-layer authorization semantics.

Maximum Potential Impact

Unauthorized users may infer team workload distribution, work schedules, collaboration patterns, and potentially sensitive operational details through exposed time-tracking metadata.