[wp-trac] [WordPress Trac] #49499: Class 'getid3_handler' not found

[WordPress Trac]

#49499: Class 'getid3_handler' not found
-------------------------------+------------------------------
 Reporter:  manjeetwp681       |       Owner:  (none)
     Type:  defect (bug)       |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Media              |     Version:  5.3.2
 Severity:  normal             |  Resolution:
 Keywords:  reporter-feedback  |     Focuses:
-------------------------------+------------------------------

Comment (by carl-alberto):

 It seems this is related to a couple of files included in the wp core for
 getID3 https://github.com/JamesHeinrich/getID3


 == Steps to reproduce the error:
 1) Error logging/debugging is enabled in a WP site and the host allows it
 2) Visit directly the location of the said files eg: ''https://example.com
 /wp-includes/ID3/module.audio-video.asf.php'' it will give out the error
 **Fatal error: Uncaught Error: Class 'getid3_lib' not found in wp-
 includes/ID3/module.audio-video.asf.php:16 Stack trace: #0 {main} thrown
 in wp-includes/ID3/module.audio-video.asf.php on line 16
 **
 Affected files
 These are the files affected in the WP core in this folder wp-
 includes/ID3/

 module.audio-video.asf.php
 module.audio-video.flv.php
 module.audio-video.matroska.php
 module.audio-video.quicktime.php
 module.audio-video.riff.php
 module.audio.ac3.php
 module.audio.dts.php
 module.audio.flac.php
 module.audio.mp3.php
 module.audio.ogg.php
 module.tag.apetag.php
 module.tag.id3v1.php
 module.tag.id3v2.php
 module.tag.lyrics3.php


 == This vulnerability is the hosting's responsibility
 Most technical users know that the path disclosure is the hosting's
 responsibility to address this issue but let's put our shoes in a simple
 user that is not very technical and can only host from the cheapest
 possible way where there is no staging and they always work in a live site
 where by default debugging is on, it would affect the user-friendliness of
 an application as most likely they will run into:

 - the full path is exposed by default and their site will be a favorite
 target for SQLI attacks and automated probes before the owners know it
 - their disk space can be maxed out when the error logs piles up
 - this user will need to hire a developer to get this coordinated to the
 hosting to get this turned off if he is not familiar in toggling the
 settings from the host


 == Possible long term solution
 Opened up an issue here in the getID3 lib
 https://github.com/JamesHeinrich/getID3/issues/235 and added a patch
 https://github.com/JamesHeinrich/getID3/pull/236 Hopefully this will be
 put into consideration and merged in the WP core eventually

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/49499#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform