Evaluate potential impact of permission handling issue
What happened
During an internal review, we discovered a logic error affecting how the app handled page restrictions under a very specific configuration. When Edit Permission Inheritance was activated on a page that had no edit restrictions at all, the app incorrectly used a Confluence REST API endpoint that removed all restrictions on that page—including view restrictions.
This could result in content on that page and its descendants being viewable to users who previously did not have permission to see it.
Corresponding Atlassian ticket: https://ecosystem.atlassian.net/browse/AMS-48520
Condition required for this issue
This issue could only occur when all of the following were true:
Edit Permission Inheritance was activated on a parent page (“root page”), and
That parent page had no edit restrictions applied,
The app processed the page and used the incorrect API endpoint.
This configuration is uncommon for typical use of the app, but it cannot be ruled out and therefore must be addressed transparently.
What we have done
The issue has been fully fixed.
The app now correctly updates only edit restrictions, leaving view restrictions intact.
The fix has been deployed to all customers. No action is required to receive it.
We created a small script for the browser’s console to help you to identify pages that may have matched these conditions (see below).
What you can do
We have prepared a small script you can run in the browser’s developer console to help you identify pages that may have matched these conditions. It lists parent pages where Edit Permission Inheritance was active (or has been active in the past) and where no edit restrictions exist.
You may want to check whether these pages contain descendants that are missing view restrictions.
To apply the script, please do the following:
Navigate to any page of your Confluence Cloud instance.
Open your browser’s developer console in the current tab.
Copy the script below into your clipboard, paste it into the console, and press Enter.
It should look similar to the following:
(async () => {
const firstUrl =
"/wiki/rest/api/content/search?cql=editinheritenabled=true%20or%20editinheritenabled=false" +
"&expand=restrictions.update.restrictions.user," +
"restrictions.update.restrictions.group," +
"children.page" +
"&limit=200";
async function fetchPage(url) {
const res = await fetch(url, { credentials: "include" });
if (!res.ok) {
console.error("HTTP error", res.status, res.statusText);
return null;
}
return res.json();
}
const allResults = [];
// Fetch first page
let data = await fetchPage(firstUrl);
if (!data) return;
allResults.push(...data.results);
while (data._links && data._links.next) {
data = await fetchPage("/wiki" + data._links.next);
if (!data) break;
allResults.push(...data.results);
}
console.log(`Fetched ${allResults.length} total results.`);
const matchingPages = allResults.filter(item => {
const users =
item.restrictions?.update?.restrictions?.user?.results || [];
const groups =
item.restrictions?.update?.restrictions?.group?.results || [];
const children =
item.children?.page?.results || [];
return (
users.length === 0 &&
groups.length === 0 &&
children.length > 0
);
});
console.log(
"Potentially affected root pages:"
);
matchingPages.forEach(item =>
console.log(`${item.title} (${location.origin}/wiki${item["_links"].webui})`)
);
console.log(`\nTotal potentially affected root pages: ${matchingPages.length}`);
})();Once the script has completed, it will list all root pages (name and link) matching the conditions described above. You can then check whether any of their descendants (child pages) should be view-restricted but currently are not.
Further questions
If you have any further questions or need assistance, please don’t hesitate to contact us via our ticketing system or write us an email.
We deeply regret the inconvenience this may have caused and appreciate your understanding.