CVE-2025-6927
ApiQueryBlock was relying only on the filter returned by
HideUserUtils::getExpression which only works for blocks targeting a
user account
Bug: T397595
Change-Id: I7bbd6ae36a11840ed6b4620b5d07fa5158ff139e
CVE-2025-6591
This is the same issue as CVE-2025-32072 (T386175), except in the
API's feedcontributions module. Escape the "Contributions" and
"colon-separator" messages so administrators cannot inject HTML
into them, triggering a potential XSS in feed readers.
Bug: T392276
Change-Id: Ic590a0d0cfc0a4a1e61859ecc57a175a8f5ec098
Why:
- action=compare was used to circumvent Lockdown
What:
- use checkTitleUserPermissions() to enforce read permissions in
ApiComparePages.
Bug: T397521
Change-Id: Id275382743957004fa7fc56318fc104d8e2d267b
(cherry picked from commit c62e4d93a33e94c7fe6f716a4747b1dbd59b3f90)
Make SqlPlatform::tableNameWithAlias() include the unqualified table
name as an alias if doing so is not redundant. This assures that the
default alias from JoinGroupBase::addJoin(), equal to the unqualified
table name, will be usable in SQL (regardless of table prefixes).
Clean up use of identifier quotes for sqlite_master tables. The called
methods expect unqualified names and a passthrough exception already
exists for sqlite_* tables.
Use "block_target.bt_user" directly in ApiQueryBlocks and BlockPager,
instead of using addIdentifierQuotes(). The "block_target" alias is
automatically added to the SQL by the rdbms layer when it's not clearly
redundant, so it is always safe to use block_target.bt_user. Also, there
is no reason for aliases to include quote characters. They are supposed
to be simple alphanumerics like column names. This makes it easy for
tableNameWithAlias() to avoid redundant aliases by checking tableName().
Avoid unneeded quotes around pg_catalog.* table names in the Postgres
installer. The relevant documentation of methods like selectField() is
that the table names be unqualified (no quotes nor dots), though dots
are still supported internally for compatibility reasons and ease of
querying schemas like pg_catalog and information_schema.
Change-Id: Ic7d7826da31f49915141692cb3bd84ed1e872e96
A crude solution for the acquireTarget() race condition. Use SQL
GET_LOCK() to lock the target from the acquireTarget() call until the
transaction is committed.
Add FOR UPDATE to the acquireTarget() SELECT, otherwise it just sees the
snapshot version of the row and inserts a new row anyway.
Add a test which reliably failed prior to the change.
Reword the ipb-block-not-found message. This is normal for simultaneous
blocks of the same target. Don't contact us. In the API, remap it to
"alreadyblocked".
Bug: T389028
Change-Id: I1fa35bf08d456a93930194786f77df389217ba61
(cherry picked from commit 2b65587e4d92e7f27661e8821b14f74ade939cfa)
Users should have 'reupload' or 'reupload-own' rights to do file revert.
Bug: T304474
Change-Id: I2d0eaeeea237286741708c2b5920fe7cca3acf50
(cherry picked from commit 7b4aee237e257954195c4d695b2cfe2a9a3b4116)
Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: I73fb416573f5af600e529d224b5beb5d2e3d27d3
Fix two problems that made it difficult to convert between Message
and MessageValue, or to write code that could accept both of them,
as exemplified by the StatusValue class:
* Implement a common interface
* Use the same internal format for message parameters
While these changes should be compatible with most of existing code,
where the authors were courteous enough to simply call methods such
as Message::numParam() and not look inside the values they return,
it is potentially a breaking change for anything that depended on
the formatted params being arrays or accessed their keys.
Example patches: https://gerrit.wikimedia.org/r/q/topic:message-param
Notable changes:
* Message and MessageValue now both implement MessageSpecifier
(only Message implemented it before).
* Message::numParam() and other static methods for encoding params
now return MessageParam objects, instead of special arrays.
Use these MessageParam objects internally in Message.
* Narrow down the return type of MessageSpecifier::getParams() (it
was just `array`, allowing any type in the array). Narrow down the
types for Message::params() and MessageValue::params() to match.
* Deprecate MediaWiki\Message\Converter. As a replacement add
MessageValue::newFromSpecifier(), which is analogous to
Message::newFromSpecifier(), but without weird legacy edge cases.
* Make StatusValue::getMessages() return MessageValues. Remove code
that converted between Message and MessageValue, no longer needed.
* Update many type declarations and comments to use MessageSpecifier
instead of MessageValue, as well as a couple of tests that depended
on implementation details.
Bug: T358779
Change-Id: I625a48a6ecd3fad5c2ed76b23343a0fef91e1b83
php documentation:
If the size of post data is greater than post_max_size, the $_POST and
$_FILES superglobals are empty.
When the action= and format= are not in the GET data,
the help page is returned in html, breaking the clients expected format.
Return api error with http status 413
Bug: T291754
Change-Id: I5906fb6b4412b161b198df0b51e2476e7e1079b8
