[wp-trac] [WordPress Trac] #63974: .mo file loaded as UTF-8 by default - non-standard and ignoring Content-Type headers

[WordPress Trac]

#63974: .mo file loaded as UTF-8 by default - non-standard and ignoring Content-
Type headers
--------------------------+-----------------------------
 Reporter:  kkmuffme      |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  I18N          |    Version:
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 wp-includes/l10n/class-wp-translation-file-mo.php

 `protected function parse_file(): bool {`

 Create a.po with content
 ```
 msgid ""
 msgstr ""

 msgid "Foo bar"
 msgstr "Foo bär"
 ```

 Run `msgfmt --check-format --no-hash a.po -o a.mo`

 Now read a.mo with parse_file() - you'll get "Foo bär" - which is wrong,
 since there is no "Content-Type: text/plain; charset=UTF-8\n" header in
 the file, therefore the .mo should not be read as if it were UTF-8
 This can be seen with:
 `msgunfmt --no-wrap a.mo -o b.po`
 Not only will you get an error for "invalid multibyte sequence" here, that
 invalid multibyte sequence will also be removed.

 If user data ends up in a .mo (which it does, since some multilingual
 plugins will save translatable strings - including customer reviews - in
 .mo files), this would potentially allow for an attack vector?

 Otherwise, this behavior at least leads to non-interoperable .mo files
 being silently accepted (e.g. plugins providing .mo files that cannot be
 converted back to .po files with basic unix tools, since any multibyte
 character will fail msgunfmt)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63974>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform