Never use an http XML-RPC endpoint for https sites - #25869
Merged
Conversation
Contributor
|
| App Name | WordPress | |
| Configuration | Release-Alpha | |
| Build Number | 33842 | |
| Version | PR #25869 | |
| Bundle ID | org.wordpress.alpha | |
| Commit | 1e63589 | |
| Installation URL | 5gc4k0cvotahg |
Contributor
|
| App Name | Jetpack | |
| Configuration | Release-Alpha | |
| Build Number | 33842 | |
| Version | PR #25869 | |
| Bundle ID | com.jetpack.alpha | |
| Commit | 1e63589 | |
| Installation URL | 4p6kg574fgn2g |
When the entered site address is https, WordPressOrgXMLRPCValidator no longer probes an http variant of the same host, and any endpoint that discovery resolves to (via redirects or RSD links) is rejected unless it is also https. Previously the username and application password were sent to the http endpoint whenever the https xmlrpc.php probe failed, and the plaintext endpoint was persisted (GHSA-qxpr-7v78-mh5g).
Older app versions could silently downgrade a site's discovered XML-RPC endpoint to http and persist it, so later XML-RPC traffic and the credentials it carries crossed plaintext (GHSA-qxpr-7v78-mh5g). Blog.xmlrpcURL returns the https-upgraded endpoint for an https site, and every credential bearing XML-RPC client is now built from it (Blog.xmlrpcApi, the Zendesk profile fetch, and the site settings credential check) instead of the raw stored value. The persisted xmlrpc and the Keychain keyed by it are left unchanged, so credential lookups still resolve; only the request endpoint is upgraded, at the point the client is constructed. This closes the downgrade regardless of launch timing or store restoration, with no migration pass.
crazytonyli
force-pushed
the
fix/xmlrpc-https-downgrade
branch
from
August 11, 2026 05:08
8cf3c89 to
edd751d
Compare
Contributor
|
Version |
3 tasks
Collaborator
Generated by 🚫 Danger |
crazytonyli
added a commit
that referenced
this pull request
Aug 20, 2026
* Never fall back to plaintext XML-RPC endpoints for https sites When the entered site address is https, WordPressOrgXMLRPCValidator no longer probes an http variant of the same host, and any endpoint that discovery resolves to (via redirects or RSD links) is rejected unless it is also https. Previously the username and application password were sent to the http endpoint whenever the https xmlrpc.php probe failed, and the plaintext endpoint was persisted (GHSA-qxpr-7v78-mh5g). * Use an https XML-RPC endpoint for https sites at request time Older app versions could silently downgrade a site's discovered XML-RPC endpoint to http and persist it, so later XML-RPC traffic and the credentials it carries crossed plaintext (GHSA-qxpr-7v78-mh5g). Blog.xmlrpcURL returns the https-upgraded endpoint for an https site, and every credential bearing XML-RPC client is now built from it (Blog.xmlrpcApi, the Zendesk profile fetch, and the site settings credential check) instead of the raw stored value. The persisted xmlrpc and the Keychain keyed by it are left unchanged, so credential lookups still resolve; only the request endpoint is upgraded, at the point the client is constructed. This closes the downgrade regardless of launch timing or store restoration, with no migration pass. * Add a release note --------- Co-authored-by: Jeremy Massel <1123407+jkmassel@users.noreply.github.com>
pull Bot
pushed a commit
to kliu/WordPress-iOS
that referenced
this pull request
Aug 20, 2026
* Rediscover the REST API root when its host does not match the site (wordpress-mobile#25903) * Rediscover the REST API root when its host does not match the site A blog's stored restApiRootURL can go stale: WP.com Simple sites advertise a public-api.wordpress.com rest_route proxy root, which breaks direct wp/v2 requests once the site migrates to Atomic and an application password starts being used, and a domain change leaves the root pointing at the old host. Because the stored value was never re-validated, features on the core REST API path (such as tags) failed with rest_no_route while WP.com v1.1 features kept working. Treat a host mismatch between the stored API root and the site URL as stale and run API discovery again, persisting the rediscovered root. When rediscovery fails, keep using the stored root so sites with unreachable or disabled discovery are no worse off than before. Roots on the site's own host are used as is, with no extra network traffic. * Propagate cancellation before falling back to the stored REST API root A cancelled API discovery surfaces as a discovery failure rather than a CancellationError, so the stored-root fallback could let a cancelled operation keep running. Check for task cancellation explicitly before applying the fallback. * Compare API root and site hosts using URL values The stale-root check parsed both the stored REST API root and the site URL strings again just to read their hosts. Fetch the site URL as a URL, reuse the already-parsed root, and compare their hosts directly, dropping the string-parsing helper. * Document the expected call frequency of createPasswordIfNeeded * Add blog properties to some events (wordpress-mobile#25908) * Attach the current site to the notifications_accessed event The notifications list spans all sites, so no single site is truly scoped to the event. Attach the currently visible (or last used) site so the account-level event carries a blog_id, consistent with other tab-access events. * Attach the site to Jetpack Stats analytics events The Stats analytics bridge (WPAnalyticsStatsTracker) forwarded every JetpackStats event without a blog_id. Pass the viewed site's ID into the tracker and stamp it on each event, so site-scoped Stats events such as jetpack_stats_card_shown and jetpack_stats_main_screen_shown carry a blog_id. * Attach the site to the editor_settings_fetched event * Attach the site to the free_to_paid_plan_dashboard_card_shown event * Attach the site to the blaze_entry_point_displayed event * Attach the site to the my_site_dashboard_shown event * Attach the site to the blogging_prompts_my_site_card_viewed event trackCardViewed is generic across dashboard cards, so this also attaches the site to jetpack_install_full_plugin_card_viewed. * Track notifications_accessed with the currently visible site Switch from currentOrLastBlog() to currentlyVisibleBlog() so the event carries a blog_id only when a site is actually on screen. When none is, track it without a site rather than stamping a stale last-used one. * Remove unused trackBlazeEntryPointDisplayed ObjC bridge The method has no remaining callers. * Attach site_type to Jetpack Stats analytics events Pass the site's BlogAnalyticsProperties snapshot to the Stats bridge instead of a bare site ID, and track through the canonical blogProperties path so every Stats event carries site_type alongside blog_id, consistent with the other site-scoped events. * Never use an http XML-RPC endpoint for https sites (wordpress-mobile#25869) * Never fall back to plaintext XML-RPC endpoints for https sites When the entered site address is https, WordPressOrgXMLRPCValidator no longer probes an http variant of the same host, and any endpoint that discovery resolves to (via redirects or RSD links) is rejected unless it is also https. Previously the username and application password were sent to the http endpoint whenever the https xmlrpc.php probe failed, and the plaintext endpoint was persisted (GHSA-qxpr-7v78-mh5g). * Use an https XML-RPC endpoint for https sites at request time Older app versions could silently downgrade a site's discovered XML-RPC endpoint to http and persist it, so later XML-RPC traffic and the credentials it carries crossed plaintext (GHSA-qxpr-7v78-mh5g). Blog.xmlrpcURL returns the https-upgraded endpoint for an https site, and every credential bearing XML-RPC client is now built from it (Blog.xmlrpcApi, the Zendesk profile fetch, and the site settings credential check) instead of the raw stored value. The persisted xmlrpc and the Keychain keyed by it are left unchanged, so credential lookups still resolve; only the request endpoint is upgraded, at the point the client is constructed. This closes the downgrade regardless of launch timing or store restoration, with no migration pass. * Add a release note --------- Co-authored-by: Jeremy Massel <1123407+jkmassel@users.noreply.github.com> * Never use an http REST API endpoint for https self-hosted sites (wordpress-mobile#25914) * Prefer the discovered REST API root over the xmlrpc-derived URL for self-hosted sites `WordPressOrgRestApi(blog:)` built its base URL from `Blog.url(withPath:)`, which rewrites the raw `xmlrpc` string. An older app version could persist an http `xmlrpc` endpoint for an https site (GHSA-qxpr-7v78-mh5g), so the self-hosted REST client — and the application password it carries as a Basic auth header — could be built on http and sent in plaintext. Prefer `restApiRootURL`, the root observed during REST discovery (https for an https site, and always written alongside the application token), falling back to the xmlrpc-derived `wp-json/` URL only when no discovered root was persisted. * Add a release note * Update strings for localization * Update app translations – `Localizable.strings` * Update WordPress metadata translations * Update Jetpack metadata translations * Bump version number --------- Co-authored-by: Tony Li <tony.li@automattic.com> Co-authored-by: Jeremy Massel <1123407+jkmassel@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Note
The issue (GHSA-qxpr-7v78-mh5g) would only occur if
httpsXML-RPC request fails buthttpXML-RPC request succeeds. It's probably not very likely. But I think it's still good to patch it.Description
When a self-hosted site was added with an
https://address, the app could silently fall back to anhttp://XML-RPC endpoint and persist it, so the username and application password were then sent in plaintext on every XML-RPC call.WordPressOrgXMLRPCValidatorno longer resolves anhttp://endpoint for anhttps://site: it stops probing an http variant of the host, and rejects any endpoint that discovery resolves to unless it is also https. This prevents new downgraded endpoints.For records already downgraded by older versions,
Blog.xmlrpcURLreturns the https-upgraded endpoint for an https site, and every XML-RPC client is now built from it (Blog.xmlrpcApi, the Zendesk profile fetch, and the site settings credential check). The persistedxmlrpcvalue and the Keychain entry keyed by it are left untouched, so credential lookups is not affected.