fix(security): Upgrade iceberg to 1.9.0 to address CVE-2025-27820

[ShahimSharafudeen]

Description

Upgrade iceberg version to 1.9.0 to address CVE-2025-27820

Upgrade the Avro version to 1.12.0 to resolve unit test failures caused by the Iceberg version upgrade.

This vulnerability originates from a recent iceberg upgrade commit : https://github.com/prestodb/presto/pull/25999/files

Motivation and Context

Impact

Test Plan

Contributor checklist

• Please make sure your submission complies with our contributing guide, in particular code style and commit standards.
• PR description addresses the issue accurately and concisely. If the change is non-trivial, a GitHub Issue is referenced.
• Documented new properties (with its default value), SQL syntax, functions, or other functionality.
• If release notes are required, they follow the release notes guidelines.
• Adequate tests were added if applicable.
• CI passed.

Release Notes

Please follow release notes guidelines and fill in the release notes below.

== RELEASE NOTES ==

Security Changes
* Upgrade Iceberg to 1.9.0 to address 'CVE-2025-27820 <https://github.com/advisories/GHSA-73m2-qfq3-56cx>'_.

[tdcmeehan]

Please look into the test failures

[steveburnett]

Thanks for the release note entry! Minor nits.

== RELEASE NOTES ==

Security Changes
* Upgrade Iceberg to 1.9.0 to address 'CVE-2025-27820 <https://github.com/advisories/GHSA-73m2-qfq3-56cx>'_.

[PingLiuPing]

Thanks, it would be nice if we can give a short summary of what have been changed from iceberg 1.8.1 to iceberg 1.9.0. Especially is there any break changes? And this help us to evaluate the next steps.

[ShahimSharafudeen]

Thanks, it would be nice if we can give a short summary of what have been changed from iceberg 1.8.1 to iceberg 1.9.0. Especially is there any break changes? And this help us to evaluate the next steps.

@PingLiuPing : I attempted to upgrade the Iceberg version from 1.8.1 to 1.9.0, but this is breaking one of our test cases:
Breaking Test Case:
https://github.com/prestodb/presto/blob/master/presto-iceberg/src/test/java/com/facebook/presto/iceberg/rest/TestIcebergDistributedRest.java#L121

In Iceberg 1.8.1, the default behavior for unauthorized users was to return a 403 Forbidden: User not authorized response. However, starting from Iceberg 1.9.0 and above, the same check seems to be bypassed, and the request returns a successful response instead.

This behavior change appears to be introduced in the following OS Iceberg PR: apache/iceberg#12197

This failing test case was originally written in OSS Presto as part of the fix for a REST session bug in Iceberg REST catalogs: #23722

Currently, I am investigating how to craft a request for an unauthorized session to reproduce the 403 Forbidden: User not authorized response in Iceberg 1.9.0 and later.

[ShahimSharafudeen]

Thanks, it would be nice if we can give a short summary of what have been changed from iceberg 1.8.1 to iceberg 1.9.0. Especially is there any break changes? And this help us to evaluate the next steps.

Root Cause of Test Failure:

In Iceberg 1.8.1, the /v1/oauth/tokens endpoint was supported for handling OAuth2 token exchanges. However, in Iceberg 1.9.0, this endpoint was removed to mitigate potential security risks, and all authentication is now handled externally through a pluggable Auth Manager.
Reference: Iceberg PR #12197

Iceberg 1.8.1 endpoint responses :

Iceberg 1.9.0 endpoint response :

In our test case scenario for validating the unauthorized user flow, the authorization details are retrieved from the header section of the /v1/oauth/tokens response, where the token details are stored under the “Authorization” header. If the response’s authorization details do not match the existing session’s authorization details, the IcebergRestCatalogServlet returns “Forbidden: User not authorized.”
Implementation Reference (Presto): Presto PR #23722

However, since Iceberg 1.9.0 no longer provides authorization details in the response, this validation logic is bypassed — causing the unauthorized scenario to succeed unexpectedly, which results in the test case failure.

@PingLiuPing @tdcmeehan — Do you have any suggestions on how to handle this test failure case? In this iceberg 1.9.0 upgrade scenario, is this particular test case check still relevant?

[ShahimSharafudeen]

This failing test case does not represent the real flow of an unauthorized user. This scenario is actually for the “Authentication None supported” case, which is why all user requests succeed there. In this test case, the previous contributor attempted to validate user details from the Iceberg response by comparing cached session details for both an authorized and an unauthorized user. After the Iceberg 1.9.0 upgrade, these user details are no longer available in the Iceberg response.

[hantangwangd]

Closing this PR in favor of #26879.