v1.8.7

Phproject v1.8.7

This is a security release that fixes several access control problems in the REST API and the Atom feed. All users should upgrade, especially instances that turn on Restrict issue access (security.restrict_access) or that use API keys.

Security fixes

The REST API ignored restricted issue access (GHSA-mpq9-v47x-3hw8)

When security.restrict_access was on, several API endpoints didn't check whether the user could access the issue. Any user with a valid API key could read restricted issues they shouldn't see, including owner and author email addresses, and could post comments on them.

These endpoints now enforce the same issue access rules as the web interface:

• GET /issues/{id}.json returns 403 for issues the user can't access.
• GET /issues/{id}/comments.json returns 403 for issues the user can't access.
• POST /issues/{id}/comments.json returns 403 for issues the user can't access.
• GET /issues.json now lists only issues the user can access. For non-admin users, it also leaves out deleted issues.
• GET /tag/{tag}.json now leaves out issues the user can't access.

The Atom feed ignored restricted issue access

GET /atom.xml?key=… could list restricted issues, either with type=all or by giving another user's username. The feed now includes only issues that the API key's owner can access.

API keys of deleted users still worked

When a user was deleted, their API key kept working for the REST API and the Atom feed. Keys that belong to deleted users are now rejected: the REST API returns 401 and the Atom feed returns 403.

Users could create issues as someone else through the API

POST /issues.json accepted an author_id from any user, so an issue could be created that appeared to come from someone else. Only administrators can set author_id now. Everyone else's issues are always created under their own account.

Issues could be attached to parents the user couldn't access

POST /issues.json and PUT /issues/{id}.json accepted a parent_id pointing to an issue the user can't access. Both endpoints now return 400 in that case, which matches how the web interface handles it.

Hardened which fields PUT /issues/{id}.json can write

The update endpoint now writes only real issue columns. It no longer accepts the computed fields from the issue detail view, such as author_name or status_name. The id field can no longer be changed, and neither can author_id or closed_date, which were already protected.

Bug fixes

• With Restrict issue access on, users who aren't in any group got an error when viewing issues and issue lists. Those pages now work as expected.

Upgrade notes

• API clients: non-admin keys now get 403 Forbidden when they request issues outside their access, where they used to get the issue's data. Clients that relied on the old behavior must use an account with the right access.
• Non-admin API keys: GET /issues.json no longer returns deleted issues for these keys. Administrators still see deleted issues.
• Integrations that set author_id when creating issues must use an administrator's API key. Otherwise the value is ignored and the key's owner becomes the author.
• No database changes are needed.

Credits

Thanks to @btarr-vc who reported the REST API access control problem responsibly. While fixing it, a wider audit of the API found the other problems listed above.