実は今年の2月頃のことですが、Movable Type 3.15を使っていた際に所謂セッション・ハイジャック脆弱性と思われる挙動を見つけてしまいました。
シックスアパート社とJVNにそれぞれ詳細とともに通知していたのですが、これが公表されたようです。

JVN:
Movable Type におけるセッション管理の脆弱性
シックスアパート:
【重要】 第三者による不正アクセスを許す危険性の対策について

こうした脆弱性がしっかりと公表され、(まだ現行の日本語バージョンではFIX版が提供されていないようですが)対処がされるのはよいことなのですが、上記の公式情報などでは詳細があまり触れられておらずユーザーに具体的なリスクが分からないようにも感じます。
少しまだ早いかなと迷うところもあったのですが、ベンダーによって告知もされたことですし一部誤った理解をされている方々もいらっしゃりそうなため、通報者として具体的な脆弱性内容を明記して啓蒙させて頂こうと思います。

■ 脆弱性の詳細
この問題は一言で言えば、セッション管理に利用しているCookie値にユーザー/パスワード情報を含んでしまっている、つまり所謂「セッションID」管理を行っていない、という点です。
参照: 安全なWebアプリ開発 31箇条の鉄則
例えばMTの管理画面へログインすると、以下のようなCookieが発行されます。
mt_user=user1%3A%3AXXXXXXXXXXXXX%3A%3A1
* XXXXXXXXXXXXXはマスクしています。
恐らくWebアプリケーションに精通している方であれば即座に問題に気付かれると思いますが、ここでUser1はログインしているユーザー名です。またXXXXXXXXXXXXXはマスクしていますが、実際にはBASE64を施した値で、どうやらユーザー+パスワードから生成したハッシュ値のようです(私はMTのコードを詳しく読んだことがないので詳しくは把握していないのですが)。ログイン・ログアウトを繰り返してもこのCookie値はユーザー名やパスワード自体を変えない限り、常に同じ内容が割り当てられます。
# この点からは、MTの管理画面へのアクセス時には常にこのCookie値のユーザー/パスワード(のハッシュ)でログイン可能/不能を毎回チェックすることでログイン状態の維持を行っているのではないか？と推察します。
この一点のみであれば遡及的にユーザーに害を及ぼすものではありません。
しかしCSS/XSSなどの他の脆弱性と組み合わせることで攻撃者がCookieを入手した場合、「恒久的」になりすましてログイン可能となってしまう、というセッション・ハイジャック脆弱性が今回の問題の本質となります。
念のため、たとえセッションID管理を行っていてもCookieが漏洩してしまえばセッションをハイジャックできてしまうことは変わりありません。
しかしながら、その場合は一度ログアウトしてしまうかCookieの有効期間が切れてしまえばCookie値は通常変更されるため(セッションIDと言われる所以です)、恒久的に影響を及ぼすことはありません。
つまり一度入手してしまえば(しかも漏洩したことはほとんどの場合被害側は気付けないかも知れません)、ユーザー名やパスワードが変更されない限り何の問題も無く成りすましてログインできてしまうことになります。
またMTの場合致命的なのは、上記のXXXXXXXXXXXXXの部分がAtom API利用時のパスワードそのものとなっていることです(管理画面-プロフィール内のAtom API 認証用トークンのことです)。
つまりわざわざCookieの偽造をしなくとも、ATOM API対応のBlogクライアント(BlogWriteとかですね)を使って苦労無くログインできてしまう訳です。
■ 対処方法
厳密には、問題が解決されているという次バージョンを使わない限りエンドユーザーレベルではなかなか難しいと思います。私はJVNへの報告では回避策として「なし」としていました。
シックスアパートのページに幾つか対策が述べられていますが、抜本策では無いでしょう。特に個人ユーザーではSSL化は難しいでしょうし(そもそもCookieにSecure属性が付けられないとhttpアクセス時に漏洩する危険性は消えないはず)。
mt.cgiやAtom APIエンドポイントURLを変えるとか、こまめにログアウトしておくぐらいでしょうか。
但し、繰り返しますが一応は他のCSS/XSS脆弱性と組み合わされない限りは顕在化はしないはずですが、こんな話も時々出てきますので、注意はしておいた方がよいでしょう。
■ 雑感とか
正直に書くとこれだけ有名なプロダクトに、こんな単純で有名な脆弱性が残っていることに当初信じられてませんでした。多分私が知らないだけで、どこかでは大きく話題になってエスカレーションされているんだろうと思って一時は放置しかけたんですが、どうもこのように対応されているところを見るとそうではないらしい・・。
今もあまり信じ切れていないのですが、本当に世間には気付かれていなかったでしょうか > コミュニティ(?)の皆さん
(嫌味とかでなく、本当にそうなんですよ・・)
もう一点。
この問題に気付いた後に色々気になって調べてみました。
主観で申し訳ないのですが、どうもPerlの場合こうしたセッション管理での問題が出やすいように思われます。
これは恐らく、例えばJava(J2EE)やPHP(は本当は触ったことはないので知識レベルですが)の場合はセッション管理のためのクラスなどがあらかじめ用意されていますが、Perlの場合はそうしたデフォルトの組み込みモジュールが無い(若しくはあまり知られていない?)ためではないかと考えています。
言語に貴賎はもちろん無いのですが、Perl技術者の方にはぜひ他山の石にして頂きたいと思います。他にも同じ脆弱性を持つPerlプロダクトがあるかも知れませんよ・・、とこっそり書いておきましょう。

【訂正:05/14】
naoyaさんやishinaoさんの指摘を受けて、あまりに煽りすぎでひどい表現過ぎたと反省したので、上記を削除(文脈が悪いので取り消し線で元文章との比較も出来るように残しておきますが)して再度真意と、上記を書いた時に勘違いしていたことも分かりましたので含めて記載しておくことにします。
例示からしますと、例えばJavaの場合(PHPはぜんぜん分かっていないので触れないことにします)、これはServer-Side Java(Servlet/JSP)ですがsessionオブジェクトをインスタンス化して紐付けたいアトリビュートをset/getすることで簡単にユーザー・セッションとサーバー側で永続的に保持したいオブジェクトを管理できます。またこの永続化手続き自体もパラメータ指定によるほぼ全自動です。
と同時にこれによりプログラマーに意識させること無く勝手に、ランダムなセッションID Cookieでセッション管理が「結果として」行えてしまいます。
一方、Perlでは例えばCGI::Sessionというモジュールが一般的なようで、これも上記とほぼ同様の機能のようですね。
# 実はここを、CGI::Sessionは単にセッションIDを発行するだけで永続的オブジェクト管理は行えないのかと思ってしまっていましたが、これは間違いでした。
但し、一つには私がある程度Perlアプリを見ていると必ずしもCGI::Sessionばかりを使っているようでもないように思われます。
ここで、セッションIDによる管理は別にこれによって100%安全になる手法ではありませんが、よりベターであり望ましいと考えられる、という理解の前提です。
(じゃあその使っていないというPerlアプリとは？との質問にはちょっと具体的にはお答えできません。ごめんなさい)
その理由を想像するに、これはPerlの利点でもあるのですがmodulableでしかもそのモジュールが非常に多岐に渡る点が他言語と比べても際立っており、これが逆に開発者によっては手法を知らずに開発してしまったり、または環境によってインストールされていない場合利用できないことにもなる(同時に配布しても本当はいいのでそうでもないとは思いますが)ので実装を躊躇する、などの状況が生まれてる原因にもつながっているのでは、ということです。
# Perlコミュニティをよく理解していないかも知れませんので、指摘などもらえると嬉しいです。
また、セキュリティ絡みやこの問題から離れて考えてみるに、結果としてデフォルトなどで用意されている機能などに開発者が依存する(流される)ことで言語間(コミュニティ間とも言えるかも)で、汎用的な手法に対するスタンスに違いが出てくるかも、というのも考察の視点としては面白いかな、と思っています。

最後に。
対処されたのは大変喜ばしいことなのですが、少なくとも私がシックスアパートさんへ通知したのは2月上旬で対応版(日本語版)が出るのが6月中旬、ということはここまで約四ヵ月かかっているということですか。
Webアプリケーションとしては今日び結構致命的(業務ではこんなバグが客にばれたら出入り禁止食らうと思ってます)と思うのですが、・・・うーん、世間的にはこんなものなのでしょうかね。
個人的感想としては、

そんなところです(^^;
追記 05/14
追記記事書きました: http://tdiary.seesaa.net/article/3630283.html