Issue Summary

Confluence 10 introduced a stricter XML parser as part of the legacy editor deprecation effort. While Atlassian has confirmed this enforcement is intentional for new content, the change also silently corrupts macro parameter values on pages that were saved under the previous, more permissive parser. This was explicitly flagged as a separate concern in CONFSERVER-81553, where the Engineering Manager noted: "The bug as described shouldn't impact already saved pages, though I can see that there may be ways that it could."

This report describes one confirmed way it does.

Steps to Reproduce

1. On a Confluence instance running 9.x or earlier, create a page containing a structured macro (not a plain-text body macro) with a parameter value that includes the character sequence ]>. For example, a ConfiForms macro with a formula parameter: id.evaluateFormula(IF([entry.created]>1734613157832,"7","6")).
2. Save the page. It saves and renders correctly.
3. Upgrade to Confluence 10 (confirmed on 10.2.14).
4. Open the page. The macro renders incorrectly because the parameter value has been stripped.

Expected Results

Pages saved on earlier Confluence versions continue to render correctly after upgrading. The stricter parser should either preserve existing parameter values or provide a migration path.

Actual Results

The macro parameter value is silently removed. The page renders with an empty or broken parameter. No error is shown to the user and no migration guidance exists.

Additional Notes:

• The affected sequence is ]> (single bracket), not ]]>. These are stored in different locations in the Confluence storage format: ]]> causes an XMLStreamException inside CDATA blocks (covered by CONFSERVER-82849 and CONFSERVER-81553). The sequence ]> inside an <ac:parameter> element is not illegal in XML 1.0 and should not be stripped.
• The sanitizer appears to be pattern-matching on ]> as a substring and removing the entire parameter value, which is more aggressive than the XML specification requires.
• The same value with a space (] >) is accepted, confirming this is a string-matching heuristic rather than an XML parse error.
• Affected pages date back to 2014 in the reporter's case, representing years of customer data rendered incorrect with no warning.

Workaround

• Workaround for new content: encode > as 

  >
  

   or ] as 

  ]
  

   in parameter values written to storage. No automated migration exists for already-saved pages.